[RFC] /var versus /srv
nicolas.mailhot at laposte.net
Fri Sep 28 16:15:40 UTC 2007
Le Ven 28 septembre 2007 14:55, Alexander Boström a écrit :
> fre 2007-09-28 klockan 11:30 +0200 skrev Nicolas Mailhot:
>> And this is broken by design. You're mirroring /var organisation
>> people have repeatedly told you this organisation was not adapted to
>> their needs. Swapping /var and /srv does not make it magically sane.
> No, they have not. The fact that /var is something you need to go
> through directory by directory to see what you need to backup and what
> you can lose is not an argument against /srv/lib. Is that what you
The fact that some stuff is nonsensically under /lib in var is no
reason to inflict /lib on /srv
>> Also you contradict yourself by insisting both on packagename
>> namespacing and taking a packagename-agnostic layout like /var/www
> No, I was suggesting bringing that dir into the fold with the others
> in /srv/lib if you move it to somewhere in /srv. Whether /srv/lib/www
> should be a shared dir for web-related packages or there should be one
> dir per package is a different question which I haven't really
> intended to comment on or even considered.
www is not the only directory with such a question and if you've not
considered the problem please refrain from advocating generic
packagename namespacing rules
>> What's the point of forcing packagename in the namespace ?
> Symmetry. Unless there's a good argument against, symmetry is useful.
Symmetry is what led to the wonderful LSB package naming no one uses.
Also the package namespace is distro-specific, forcing it on /srv will
result in distro-specific file layout. The nice thing about the FHS is
it strives to be distro-agnostic.
> It's not about forcing, it's about finding something that can be
> agreed upon so that you can add it to the FHS.
You have two ways to get new stuff in LSB/FHS.
Define carefully though stuff that works and everyone is happy to use,
and define æsthetically pleasing stuff that has no relevance to
reality but feels good in a spec.
The first way is more work.
More information about the fedora-devel-list