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