[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