Bug#613143: there is /usr/lib64 symlink but no /usr/local/lib64
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. <ballombe@debian.org>
Imagine a large red swirl here.
Reply to: