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
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
