[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [RFC] /var versus /srv

Now can people _please_ discuss:

      * How to justify this change in the release notes. ("FHS told us
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).

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]