Configuration files in /usr

[Jason L Tibbitts III]

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.

An example package is hwdata:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=225893

Patrice mentions in that bug that FHS covers us here, but the
guideline only asks that deviations from FHS be rationalized.

 - J<

[Ralf Corsepius]

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.

It's essentially the same rationale, as why I consider FPC's decision to
drop %config on init-scripts a fault.

2. There exist real (designed to be user-customizable) config files,
which for traditional reasons live outside of /etc. Pedantically
speaking these should not live outside of /etc, but in practice you
can't change them, at least not easily and at least not "immediately".

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.

>  An example package is hwdata:
>  https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=225893
>  
>  Patrice mentions in that bug that FHS covers us here, but the
>  guideline only asks that deviations from FHS be rationalized. 
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.

Ralf

[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