[RFC] /var versus /srv

Alexander Boström abo at kth.se
Fri Sep 28 05:47:52 UTC 2007


tor 2007-09-27 klockan 21:51 -0400 skrev Kelly:

> Nah, just do what they did in openSUSE when the decision was made to move the 
> Gnome stuff from the /opt folder to the /usr folder - have "compat" packages 
> that create symlinks to the old locations, so that if the user has scripts 
> that assume the stuff's still located in /var, they will still work properly.  
> I'm not entirely sure how well this would work with SELinux, though. 

A httpd-compat-dir package with a %pre that moves /var/www
to /srv/lib/www and makes /var/www a symlink? That might work,
sometimes, but it will also break something in some systems and fail to
install on others. (Different filesystems, one with, one without ACLs.
One big, one small filesystem. Fill up the /srv filesystem so some other
service breaks. /var/www is a network mount, /srv is local. I could go
on...)

This change can not be made transparent. You have to put the change in
the release notes and let the admin sort out the mess after an upgrade.
That's all you can do.

Now can people _please_ discuss:

      * How to justify this change in the release notes. ("FHS told us
        to"?)
      * List of directories in /var that are "wrong".
      * Suggestions for what /srv structure to propose for the next FHS.

I've already given my opinion about /srv, but I'll repeat it: If you
necessarily need to impose a structure on it, put that structure only
in /srv/lib. Make it /srv/lib/<packagename>.

You also need to make sure you follow the FHS or change the FHS
regarding what goes in /var and what goes in /srv. To me, the FHS seems
rather clear: /var is for files only the app should touch (and perhaps
an admin too but preferably not), while /srv is for files which the
users or admins need to find, look at and change. One problem is that
something like that might change through the lifetime of an application,
but you can't start moving things around because of that.

/abo





More information about the fedora-devel-list mailing list