On Thu, May 08, 2014 at 01:20:42PM -0700, Jonathan Nieder wrote: > Bill Allombert wrote: > > On Thu, May 08, 2014 at 12:51:05PM -0700, Jonathan Nieder wrote: > > >> FWIW I don't mind if you tweak the wording. > >> > >> Unfortunately it's not just <qual> = 32 or 64[1]. Luckily the only > >> ones that would be relevant the way Debian uses <qual> are > >> > >> <qual> = 32 (mips, tilegx) > >> <qual> = 64 (mips, powerpc, x86) > >> <qual> = x32 (x86) > > > > However the FHS version mandated by policy does not include libx32, > > so it could be argued that there is no need for a FHS exception for > > libx32. > > If I understand correctly then alas, no --- the FHS meaning of <qual> > is open ended. > > When it describes lib32 and lib64 it says > > The 64-bit architectures PPC64, s390x, sparc64 and AMD64 must > place 64-bit libraries in /lib64, and 32-bit (or 31-bit on > s390) libraries in /lib. > > The 64-bit architecture IA64 must place 64-bit libraries in /lib. > > This is a refinement of the general rules for /lib<qual> and > /usr/lib<qual>. > > In other words, there are rules elsewhere in the document about how > lib<qual> works generally for lib32, lib64, libx32, libxyzzy, or > whatever, and here are the more specific rules that govern lib, lib32, > and lib64 on PPC64, s390x, sparc64, AMD64, and IA64. > > How about the following (text as before, except a parenthesized phrase > added)? > > The requirement for /usr/local/lib<qual> to exist if /lib<qual> or > /usr/lib<qual> exists (where lib<qual> is a variant of lib such as > lib32 or lib64) is removed. > > "such as" should cover any future lib directories.
I took the liberty to apply your wording (also I fixed a minor typo in the SGML entity, and I added your name in the changelog) Cheers, -- Bill. <ballo...@debian.org> Imagine a large red swirl here. -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140517171802.GB5861@yellowpig
