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.
Thanks,
Jonathan
--
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/20140508202042.ge9...@google.com
