Re: Multiarch interfaces

[Goswin von Brederlow <goswin-v-b@web.de>]

Steve Langasek <vorlon@debian.org> writes:

> On Mon, Nov 28, 2011 at 12:38:01AM +0100, Guillem Jover wrote:
>> > > Except for things like possibly firmware, which AFAIR there seemed to
>> > > be consensus should be kept as arch:all for now (otherwise they'd
>> > > require Packages file for lots of architectures), the rest require
>> > > run-time support from libc. The problem with adding the arch from
>> > > the libc package is that's a chicken and egg situation.
>
>> > What libc support do you mean?  All per-architecture executables should have
>> > dependencies on the libc package for their arch anyway, so I don't see how
>> > libc support really enters into this.
>
>> Yes, I meant them needing the dynamic linker and libc.so. So if we are
>> on arch:amd64, want to install pkga:i386, and libc:i386 is the one
>> doing the dpkg --add-architecture i386, then apt will not be able to
>> nicely present the package to the user before the user has installed
>> it. Hope this clarifies.
>
> Oh, ok.  I had understood "the rest of the architectures" rather than "the
> rest of the packages" - thanks for the clarification.  Yes, it would be a
> bootstrapping problem to have libc registering the architecture with dpkg.

Wouldn't it make more sense to highjack the multiarch-support (the
native one) package and have it ask a debconf question wether to
activate i386 on amd64 and amd64 on i386 and so on?

And qemu-armel would add armel support, not the libc:armel.

I don't see how the libc would be the right place for this. That just
gives you a chicken&egg problem.

MfG
        Goswin