Package: dpkg
Version: 1.15.5.6
Severity: wishlist
Hi,
with apt adding the first parts for multiarch support and multiarch
debs appearing in the archive I think it is time to think about how
multiarch systems should be configured. Since dpkg is the common and
lowest point I beliefe the configuration should be there and should
also cover the cross-compile use case. The frontends like apt,
aptitude, cupt, adept, ... should all use the dpkg config to configure
their multiarch settings.
Currently dpkg rejects all packages that are not architecture all or
the same architecture as dpkg itself. This will have to change to
allow the following use cases:
* Always natively executable architectures
Some architectures can execute multiple architectures. For example
amd64 can execute amd64 and i386 binaries. On such systems dpkg should
come preconfigured to allow those architectures to be installable by
default.
But since one can for example disable kernel support for 32bit
binaries on amd64 this must still be configurable to limit it to just
the native architecture.
It might also be helpfull to prioritize the architectures so for
example mips will prefer n32 ABI over o32 ABI over n64 ABI in
frontends.
* Sometimes natively executable architectures
Similar to the previous case i386 can execute both i386 and amd64
binaries. But only if a 64bit kernel is installed and running. Dpkg
should not default to allowing amd64 packages but it should be easy to
configure for it. Same goes for mips, mipsel, ppc. I don't think this
can be automated (see qemu case below) since installing a 64bit kernel
does not mean a 64bit kernel will always be running.
Ia64 is also a special case here as older cpus have hardware support
to execute i386 binaries while newer cpus need full emulation.
Again priorities would be usefull since for example i386 binaries on
ia64 are rather slow even with hardware support. Frontends should only
ever install i386 binaries there if there is no ia64 flavour or the
user (or dependencies) requested it.
* emulated executable architectures (qemu-<arch>, ia32 emu on ia64)
When qemu-armel is installed it configures the kernels binfmt-misc to
execute qemu every time a armel binary gets called. The execution of
qemu becomes transparent to the user. From a users point of view it
looks like the system has learned to run armel binaries.
It would be nice if installing qemu-<arch> (or another package) would
automatically configure dpkg to allow the installation of packages for
<arch>. But it should be clear that it is a 2nd class architecture so
that frontends like apt, aptitude, cupt, adept will allways prefer the
natively executable architectures.
* cross-compiling
For the purpose of cross-compiling one needs to install the right
libraries for that architecture. The design of multiarch includes this
use so that multiarch packages for libraries can be used for
cross-compiling as is. Some details (specifically handling the -dev
packages) are still unclear but the use case is there and just needs
some testing to iron out.
Unlike the other cases it is not OK to install binaries for the
cross-compile architecture as the cpu can not execute them. Only
libraries are usefull. From the package point this means only packages
with 'Multi-Arch: same'. Lets call this a 3rd class
architecture. Again frontends need to know the architecture is 3rd
class so they can limit the available packages for that architecture
to libraries.
I think it would be nice if users could configure their system for
multiarch by installing something. For example on i386 the user could
run
apt-get install multiarch-amd64 multiarch-armel cross-compile-mipsel
That should pull in qemu-armel as additional package and configure
dpkg (and thereby apt, aptitude, cupt, adept, ...) to allow those
architectures. Binaries for i386, amd64 and armel should be allowed
and libraries for i386, amd64, armel and mipsel.
To that end I think it would be good if the multiarch configuration
could be done by dropping files into /etc/dpkg/dpkg.cfg.d/ that would
add an architecture as 1st, 2nd or 3rd class with some priority. There
should also be a simple way for frontends to get at that information
(libdpkg?) and for users to view it (dpkg --print-architectures, dpkg
--print-multiarch?).
I hope I described the goal for this adequately so a discussion can be
started on how to best achieve it.
MfG
Goswin
-- System Information:
Debian Release: squeeze/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.31.6-xen-2010.02.18 (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=de_DE (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/dash
Versions of packages dpkg depends on:
ii coreutils 8.4-1 GNU core utilities
ii libc6 2.10.2-6 Embedded GNU C Library: Shared lib
ii lzma 4.43-14 Compression method of 7z format in
dpkg recommends no packages.
Versions of packages dpkg suggests:
ii apt 0.7.25.3 Advanced front-end for dpkg
-- no debconf information
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
