On Tue, Nov 29, 2011 at 12:45:25AM +0100, Bill Allombert wrote: > This is the relevant part of the FHS (ill-advised imho, but required by the > LSB): > > ------------------------------------- > > 6.1.5. /lib64 and /lib32 : 64/32-bit libraries (architecture dependent) > > 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. > > Rationale: > > This is a refinement of the general rules for /lib<qual> and > /usr/lib<qual>. The architectures PPC64, s390x, sparc64 and AMD64 support > support both 32-bit (for s390 more precise 31-bit) and 64-bit programs. > Using lib for 32-bit binaries allows existing binaries from the 32-bit > systems to work without any changes: such binaries are expected to be > numerous. > IA-64 uses a different scheme, reflecting the deprecation of 32-bit binaries > (and hence libraries) on that architecture. > > ------------------------------------- > > Of the five architectures mentioned above, only two are supported by full > Debian > distributions: ia64 and amd64. (full support for s390x might appear in the > future). > Since ia64 is listed as an exception, only amd64 is concerned by this FHS > part. > (Note that the FHS ignores alpha and hppa64) > > As far as Debian is concerned /lib32 and /lib64 are wart necessary for binary > compatibility > with other systems. Should we close this then?
In any case I'm not quite sure whether shipping files in lib64 in amd64 packages (juffed/juffed-dev and zynaddsubfx-dssi do this now) is OK. -- WBR, wRAR
signature.asc
Description: Digital signature
