Re: Multiarch interfaces
On Fri, 2011-11-25 at 15:57:59 -0600, Steve Langasek wrote:
> On Fri, Nov 18, 2011 at 10:45:06AM +0100, Guillem Jover wrote:
> > > Maybe we could have a "multiarch-config" binary package provided by
> > > dpkg that only provides a debconf interface to enable/disable
> > > supplementary architectures. And the default answer could be changed
> > > for each vendor/architecture combination.
>
> > The thing possibly needed is a mapping from native arch to supplementary
> > arches, supported by specific CPUs (not just amd64-i386), say:
>
> > amd64 → i386
> > ia64 → hppa, i386
> > s380x → s380
> > mips ←→ mipsel
> > armhf → armel, arm
> > armel → arm
> > powerpcspe → powerpc
> > ppc64 → powerpc
> > etc.
>
> > 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.
There's also the quite exceptional case where a package is arch specific
but does not depend on libc, like libaio, which only provides syscall
stubs.
regards,
guillem
Reply to: