On Sat, Jan 13, 2007 at 04:37:11PM -0800, Steve Langasek wrote: > 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. >
Note that in that when multiarch will arrive, you will have to add a conflict between libpango [i386] and ia32-libs-gtk [amd64], because both of them will ship the same files. This case has not been planned in the current dpkg patches. It's the argument which make us revert the use of /usr/lib/i486-linux-gnu for libc6-dev-i386 one year ago. -- .''`. Aurelien Jarno | GPG: 1024D/F1BCDB73 : :' : Debian developer | Electrical Engineer `. `' [EMAIL PROTECTED] | [EMAIL PROTECTED] `- people.debian.org/~aurel32 | www.aurel32.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
