How to depend on 32bit libs on amd64? (and what to do with ia32-libs)
ftpmaster: Please comment on the last section concerning DAK behaviour.
Hi,
before Lenny ftpmaster asked us (ia32-libs maintainers) to do
something about the mess that is ia32-libs. Specifically that it is a
HUGE source duplication and a security nightmare. Unfortunaetly there
wasn't enough time before the release to get a new solution
(ia32-apt-get) into a stable state. Now that Lenny is out the problem
can be attacked again. The major remaining problems are how to
transition from ia32-libs to ia32-apt-get and how packages can depend
on 32bit libs then. (Which actualy hinge on the same problem.)
Current state: ia32-libs + ia32-libs-gtk
----------------------------------------
The ia32-libs(-gtk) source package contains precompiled i386 deb of
packages (taken from testing i386) and for each deb the respective
source package. The debian/rules file then unpacks the i386 debs,
moves some files, fixes some files and then builds the ia32-libs(-gtk)
deb out of that. This results in ~500MB source package and ~80MB
binary packages. And for every new version of any of the contained
packages there should be a new ia32-libs(-gtk) version causing a new
~600MB upload.
New solution: ia32-apt-get
--------------------------
Ia32-apt-get provides wrappers for dpkg.deb and apt-get that allow
installing deb packages from an i386 repository (or local file)
directly. The apt-get wrapper handles mangling the Packages file from
i386 during download so apt can use it and the dpkg.deb wrapper
handles converting i386 debs to amd64 / ia64 during unpacking. Through
this every i386 package in Debian (or other apt repositories) becomes
available on amd64 / ia64 as well. In case of binary/data packages the
package name remains as is while for library packages the name is
prefixed with ia32- to allow both 64bit and 32bit flavours of
libraries to be installed. Package updates become available to the
user the moment they hit the archive without needing an extra upload
or testing migration.
Transition plan
---------------
For obvious reasons ia32-lib* and ia32-libs(-gtk) must conflict with
each other as they contain the same libraries. They basically
represent moving a file from one package (ia32-libs) into another
(ia32-lib*). As such a "Conflicts: ia32-libs (<< 3.0~~), ia32-libs-gtk (<<
3.0~~)" and "Replaces: ia32-libs (<< 3.0~~), ia32-libs-gtk (<< 3.0~~)"
are neccessary. That should solve most packages. BUT:
Some library packages contain conffiles. How do I handle the case
of a conffile moving from ia32-libs to ia32-libfoo correctly?
Also how do I make it so that an existing ia32-libs package would pull
in the respective ia32-lib* packages on upgrades? The obvious solution
is to create ia32-libs(-gtk) meta packages that depend on the
respective ia32-lib* packages. This brings us to the main problem of
this mail:
How to depend on 32bit libs on amd64?
=====================================
The ia32-libs(-gtk) package should look somewhat like this:
Package: ia32-libs
Version: 3.0
Depends: lib32gcc1, libc6-i386, lib32z1, lib32stdc++6, lib32asound2,
lib32ncurses5, ia32-libattr1, ia32-libx86-1, ia32-libpam0g, ...
The problem I see here is that ia32-libattr1, ia32-libx86-1,
ia32-libpam0g, ... are not in main as far as DAK is concerned. They
are not known at all in the Debian archive. As such I think
ia32-libs(-gtk) could never transition from unstable to testing on its
own. On the users system they are also not available untill
ia32-apt-get is installed and apt-get update has been run. On a fresh
system a simple "apt-get install ia32-libs" would not be possible.
And it is not just the ia32-libs(-gtk) dummy packages that are
affected:
% apt-cache rdepends ia32-libs ia32-libs-gtk | sort -u | xargs
eagle fglrx-glx-ia32 ia32-libs-gtk ia32-sun-java5-bin
ia32-sun-java6-bin lib32asound2 lib32asound2-plugins lib32bz2-1.0
lib32ncurses5 lib32z1 libc6-i386 libwine libwine-capi libwine-cms
libwine-esd libwine-gl libwine-gphoto2 libwine-jack libwine-ldap
libwine-nas libwine-print libwine-sane nspluginwrapper nvidia-glx-ia32
nvidia-glx-legacy-71xx-ia32 nvidia-glx-legacy-96xx-ia32
teamspeak-client teamspeak-server vmware-package
Those packages should depend on the specific ia32-lib* package they
actually need instead of the ia32-libs(-gtk) meta packages. Again
creating a dependency on a seemingly non-existing package.
Does anyone have an idea how to solve this in a way that DAK remains
happy and so that e.g. "apt-get install vmware-package" will pull in
ia32-apt-get and then the right libs?
MfG
Goswin
PS: The most difficult case is nspluginwrapper. I think all other
packages could be removed from amd64 and use the i386 package
directly.
Reply to: