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