Re: Multiarch interfaces
Guillem Jover <guillem@debian.org> writes:
> The other interface change is related to the --foreign-architecture
> option, the problem with it comes from the fact that the architectures
> supported by the database are not configuration, they are state. This
> shows up in several ways. When a front-end needs to load the list of
> architectures, it needs to get someone to parse dpkg.cfg files, this
> is currently done by dpkg itself, and the list can be retrieved with
> --print-foreign-architectures, the problem comes when wanting a
> front-end to load them through libdpkg. Making the latter have to
> execute «dpkg --print-foreign-architectures» would be suboptimal, and
> making libdpkg have to load dpkg.cfg would be distasteful. 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, and it makes it fairly easy to accidentally remove architectures
> required by the database. 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. (I'll probably rename --del-architecture
> to something like --remove-architecture before pushing, to match the
> convention in the rest of the dpkg CLI).
>
> regards,
> guillem
Please add support for more than just an on/off switch. An architecture
can have different "class":
1) first class architecture
The hardware can natively run this architecture. Anything can be
installed for it.
2) second class architecture
The hardware can not natively run this but there is an emulator
(e.g. qemu-armel) installed. Some things can not be installed for this
architecture and a first class architecture should be used by frontends
whenever possible. Worst case would be installing an armel /bin/sh on
amd64.
This probably is nothing dpkg has to care about but it should have the
information so frontends can get to it and do the right thing
(e.g. prefer first class archs, ask really loudly before replacing
anythign essential with a second class arch).
3) cross-compile architecture
The hardware may or may not be able to run this at all, natively or
emulated. Only Multi-Arch: foreign packages should be installable for
this architecture.
This is something dpkg could ensure but might also just be left to
frontends. But again there should be a central place to keep the
information.
MfG
Goswin
Reply to: