Re: Multiarch interfaces
On Fri, 2011-11-18 at 12:01:57 +0100, Raphael Hertzog wrote:
> On Fri, 18 Nov 2011, Guillem Jover wrote:
> > Another issue is that if the list of foreign architectures is on the
> > configuration files it makes it slightly more tricky to cross-grade
> > dpkg
>
> I don't follow you here. What's the problematic scenario?
dpkg built for amd64 (native), i386 (foreign arch) configured in
say /etc/dpkg.cfg.d/arch, several i386 packages installed. When one
cross-grades dpkg itself from amd64 to i386, suddenly all amd64
packages would be force-architecture worthy and as such broken for
any multi-arch enabled front-end.
With the new db, dpkg implicitly adds the native arch to the file (not
tagging it specially), and any additional foreign arch is added too.
So in the previous case the file starts with amd64, the user or another
package adds i386 through --add-architecture. When cross-grading dpkg
the file has both, and knows which one is the native one, based on the
internal knowdlege of what it was itself built for, so no
inconsistencies.
> > I've fixed all this by replacing the --foreign-architecture option with
> > two new commands --add-architecture and --del-architecture which will
> > perform sanity checks and store and load the architecture list
> > (including the native arch) in an internal db file under /var/lib/dpkg.
>
> This look ok to me too. --print-foreign-architectures must stay of course,
> APT already relies on this interface.
Well it should stay because it makes sense, not because there's
already users of an option not present upstream.
> Ubuntu will have to come up with a small transition strategy since they
> modified dpkg to provide a supplementary configuration file precisely
> to auto-enable i386 on amd64.
Yes, that's for them to cope with.
> 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.
The problem is that enabling additional arches might incur a cost to
the user even if they are not going to use those, if for example the
front-end automatically starts downloading Packages files for those
other arches.
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.
If it were to be decided to create a multiarch-config package, I don't
think dpkg should be providing such package, generating it from the
same place multiarch-support seems to make more sense. Shipping the
mapping table in dpkg might make some sense though. The problem is
when conflacting support with activation in the same interface.
Things like qemu could add additional architectures if they provide
transparent cpu emulation, but doing so automatically would incur the
same costs. Probably qemu would add it to such a mapping table for
example, as supported but not activated.
regards,
guillem
Reply to: