[Fedora-packaging] Configuration files in /usr

[Patrice Dumas]

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

# vendor
%_datadir/%name/the_data_or_conf.cnf
# site wide
%config(noreplace) %_datadir/%name/custom/the_data_or_conf.cnf
# local
%config(noreplace) %_sysconfdir/%name/the_data_or_conf.cnf

> In this particular case, I agree with the packager to make these files 
> %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
doing reviews.

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.

--
Pat