On Wed, Feb 28, 2007 at 06:46:28AM +0100, Ralf Corsepius wrote:
On Tue, 2007-02-27 at 23:06 -0600, Jason L Tibbitts III wrote:
> Any opinions on %config files in /usr? This seems to violate all
> sorts of common sense surrounding shared or read only /usr, but does
> not seem to be mentioned in the guidelines.
This question seems overly simplistic to me.
1. "%config" doesn't necessarily mean this file to be a configuration
file. It means, the packager has taken into account that users can have
customized certain files and wants to play it nice to those users and
wants to avoid trashing their work.
What users should customize and what they shouldn't touch should be
well separated in my opinion. Users should always be able to add their
own customizations without touching the defaults which are set by
the vendor/packager/upstream. Having %config files in %_datadir often
means that there is no easy way to override the default conf. Marking
those files %config might be better than nothing, but allowing users to
override/add stuff is even better.
3. There is a flaw/leak/gap inside of the FHS: /etc only covers
"Host-specific system configuration" and doesn't cover "site-wide
configuration", while /usr/share is supposed to take "arch-independent
files". This has lead to problems when it comes to site-wide config
files, because /etc definitely is not the correct place to put them.
That's a good point, but in general this is not the real issue. It
adds another location where apps using the config should search but
at least some data/config files should be left under the vendor
control. For a virtual example, we could have
# site wide
In this particular case, I agree with the packager to make these
%config. Most users won't touch them, therefore won't see any effects.
But those who touched them (E.g. because they add an usb-id for this
freaking bleeding edge usb-device they just installed), will be grateful
when rpm doesn't throw away their work on update.
It would be much better if the user could add this usb id in another
file, be it in /etc for local customization or soewhere else below /usr
for site-wide customization.
In any case, I admit that I may be using the wrong argument (compliance
to FHS) to chase another issue (no distinction between user and vendor
data), because in most cases defaults are in %_datadir while
customizations are in %_sysconfdir. And indeed I see no reason why we
should necessarily ship only packages that separate clearly vendor and
user config -- still it could be something we want to consider when
As a first note, it is not always relevant to distinguish between vendor
and user conf, in many case the vendor conf is of no use.
As a second side note, there are cases where the vendor files are in
%_sysconfdir but cannot be kept when customizing, losing the vendor
defaults. In that case there may be something wrong though there
won't be FHS/rpmlint warning issues.
Last I think that hwdata falls in the case where distinction between
vendor and user data is relevant.