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 -- Fedora-packaging mailing list Fedora-packaging@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-packaging
