[Fedora-packaging] Re: Packaging into /srv? (was: FHS Compliance?)

Nicolas Mailhot nicolas.mailhot at laposte.net
Sat Oct 21 11:29:02 UTC 2006


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




More information about the fedora-devel-list mailing list