[RFC] /var versus /srv

[Nicolas Mailhot]

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
>> when
>> 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
> mean?

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
>> as
>> example.
>
> 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.

Regards,

-- 
Nicolas Mailhot