[RFC] /var versus /srv

Casey Dahlin cjdahlin at ncsu.edu
Fri Sep 28 07:07:21 UTC 2007


> Now can people _please_ discuss:
>
>       * How to justify this change in the release notes. ("FHS told us
>         to"?)
>   
There's been enough reasons in this thread, just a matter of aggregating 
them a bit. Immediately to mind are the divergent backup considerations.
>       * List of directories in /var that are "wrong".
>   
/var/www, /var/ftp, /var/lib/mysql right off the top of my head. There's 
probably more. Let's keep going
>       * Suggestions for what /srv structure to propose for the next FHS.
>
>   
This is big enough that we might want to get the discussion going 
outside this mailing list before we spec this out
> 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>.
>
>   
I agree. This is a fairly good compromise between all the issues brought 
up here. The FHS proposal might do something a little different, but 
this is the best solution for the present.
> 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.
>
>   
One (rather extreme) way to look at it is that /var contains information 
that should be stored in RAM except for 2 considerations: 1) it is too 
large, 2) its relevance may extend beyond the life of the process or 
across reboots. /var is a place for the application to write down what 
it is actively in the process of doing or where it left off when it last 
terminated. (This is how it SHOULD be IMHO. For now we should try not to 
break FHS beyond what we're doing now).
> /abo
>
>
>   




More information about the fedora-devel-list mailing list