On Sat, Jan 13, 2007 at 10:19:52AM +0100, Loïc Minier wrote: > On Fri, Jan 12, 2007, Steve Langasek wrote: > > If you're going to use non-standard paths at all, why would you not move > > this to /usr/lib/i486-linux-gnu, which is also already part of the system > > lib path in etch and is much better future-proofed than the alternatives?
> I'm willing to use whatever is blessed by bi-arch as I think it would > make sense to support bi-arch in the lenny lifecycle; I think the > adaptation that libpango needs are relatively close in both cases (but > biarch will need a second build of course). Biarch is broken on amd64 in ways that are not reconcilable with the FHS. And /emul as a file path is totally blecherous, and an obstacle to ever reusing binary packages for multiarch. Multiarch is the only way forward from the current mess. I want to be able to completely rid ourselves of biarch hacks for lenny. > (FYI, pango can be built with multi-arch support but > /usr/lib/i486-linux-gnu, is then used as libdir, not just for module > files and modules.) Right, you wouldn't want to be moving the libs into /usr/lib/i486-linux-gnu at this point. > It seems to me 64-bits libs for i386 use /usr/lib64 in bi-arch (I > checked lib64z1 and lib64asound2). It's less clear to me what to use > for 326bits libs on 64-bits arches: lib32z1 and lib32asound2 use > /emul/ia32-linux/usr/lib; is this correct? Does it make sense that use > this path? It is unfortunately the only install path supported by biarch because of the symlinking solution that was adopted for /usr/lib32, yes. On Sat, Jan 13, 2007 at 10:28:22AM +0100, Goswin von Brederlow wrote: > > On Fri, Jan 12, 2007 at 08:19:18PM +0100, Goswin von Brederlow wrote: > >> As for using /usr/lib32 on i386 that is totaly up to you. On i386 > >> /usr/lib32 does not yet exist but I don't see a reason not to create > >> it. Note that you can't have system libraries in /usr/lib32 since it > >> is not a default lib dir on i486. > > If you're going to use non-standard paths at all, why would you not move > > this to /usr/lib/i486-linux-gnu, which is also already part of the system > > lib path in etch and is much better future-proofed than the alternatives? > Because binutils does not support /usr/lib/i486-linux-gnu and amd64 > already uses lib32 (and binutils supports it there). That shouldn't prevent using /usr/lib/i486-linux-gnu/pango as a modules subdir, because binutils doesn't need to know about /that/ path. It does prevent moving libpango.so to /usr/lib/i486-linux-gnu until binutils supports it. If the two paths are coupled in an inconvenient fashion in the pango build rules such that the maintainers prefer to keep them all in one directory, then yes, /emul/blah/barf is the best option for now. > lib32 is standardized in the FHS: > | /lib<qual> : Alternate format essential shared libraries (optional) > | Purpose > | There may be one or more variants of the /lib directory on systems > | which support more than one binary format requiring separate > | libraries. [14] And on amd64, the FHS specifies that /usr/lib is supposed to be *32*-bit, and /usr/lib*64* is the one to use for 64-bit biarch files, the exact opposite of all other biarch platforms. The FHS provides no useful guidance here. We have to break the FHS anyway, we might as well be doing it in a least-awful fashion by looking towards multiarch to the greatest extent currently possible. > Anyway, the conditional use of /usr/lib32 as with the revised > ia32-hack patch posted yesterday doesn't require i386 to use > /usr/lib32 but allows amd64 to do so. That would be the savest bet. It's still bletcherous special-casing IMO. Maintainer's choice whether to adopt this solution in the short term, but it's just going to mean changing again as we move to a solid multiarch solution. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/
