Aurelien Jarno <[EMAIL PROTECTED]> writes:
> 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.
Thanks for reminding us. I knew there was some reason not to use
multiarch dirs yet. :)
MfG
Goswin
