Le samedi 21 octobre 2006 à 13:06 +0200, Axel Thimm a écrit : > On Sat, Oct 21, 2006 at 06:58:19AM -0400, Matthew Miller wrote: > > On Sat, Oct 21, 2006 at 04:14:51AM +0200, Axel Thimm wrote: > > > That's correct. Furthermore the FHS supports different hierarchies > > > below /srv depending on the site's needs. For example a server hosting > > > project1.org and project2.org would use > > > /srv/project1.org/www and > > > /srv/project2.org/www > > > So /srv should be kept free of any package bits. I'm copying the > > > packaging list, perhaps it's worth noting in the guide. > > > > As noted in the bug, I think that default, package-managed files should be > > packaged into /usr/share/somewhere, > > I agree. > > > but /srv/www (or /srv/www/something/) should be the default (empty, > > except maybe a README) document directory. > > No, /srv should exist, but otherwise be empty from the vendor's POV > (e.g. no package should own/place anything beneath /srv). We package TFTP, FTP, SMB, CIFS, DAV servers... They all need a default root in their config file. The FHS makes it abundantly clear this root must be somewhere in /srv. We can't refuse to choose a default because: 1. most users want us to choose a default so things "just work" 2. it's not a mere matter of writing a string in a config file: when several apps use the same resource you need to coordinate them, it has security and selinux impacts, etc 3. increasing variability only hurts documentation. If we don't decide people will make random choices in howtos that will be blindly followed because most people don't care and don't want to choose themselves You could make the very same argument for package naming - since there is no standard and any choice will always be suboptimal in some cases why even attempt to write Fedora Naming Guidelines? Well we wrote the damn guidelines and they're bloody useful. We don't have the freedom of the FHS to refuse to make contentious choices. We're responsible for an actual system. That requires making operational decisions. (And BTW we have historically made these decisions, only we chose roots in parts of the filesystem the FHS declared wrong, so maintaining the status-quo won't make us any more FHS compliant quite the contrary) -- Nicolas Mailhot -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list