[RFC] /var versus /srv

[Alexander Boström]

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?

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

> What's the point of lib in srv ?

As I mentioned, it's to play nicely in /srv.

> What's the point of forcing packagename in the namespace ?

Symmetry. Unless there's a good argument against, symmetry is useful.

Basically, if you're hoping to amend the FHS, you should concentrate on
one or two subdirs in /srv and try to reserve those. That would
be /srv/lib with /srv/lib/<packagename> when that is appropriate. You
could also argue that sometimes package names are not relevant. Then you
need to define a different structure and for that structure find another
subdir name in /srv that is not likely to already be in widespread use.

> Sure some stuff is package (and often package-version) specific, like
> database files. But a lot of it is completely package-agnostic. You
> should not force a stonger coupling than is technically required just
> because it makes packager life easier.

It's not about forcing, it's about finding something that can be agreed
upon so that you can add it to the FHS. Everyone is free to use /srv as
they like, which is what amending the FHS (or changing stuff in Fedora
without going through FHS) is going to conflict with.

/abo