Re: How to depend on 32bit libs on amd64? (and what to do with ia32-libs)
* Goswin von Brederlow [Mon, 30 Mar 2009 14:33:32 +0200]:
Hello, [-mentors only Bcc'ed to drop it from the discussion]
Executive summary: concerns about ia32-apt-get raised, lesser hack
proposed for comments.
> 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.)
Has there been any public discussions about ia32-apt-get, and consensus
that it is an acceptable solution? To be honest, I’m not sure at all it
is actually a better solution than the 500 MB source package.
For the benefit of others, so that they can comment, I’ll mention how it
works. Mainly, ia32-apt-get dpkg-divert’s /usr/bin/apt-get and
/usr/bin/dpkg-deb.
For apt-get, it intercepts the “update” operation, calling apt-get.real
first in an alternative root for the host arch (/var/lib/apt/native),
then calling apt-get.real again for the foreign arch (/var/lib/apt/foreign),
and then doing gross sed'ing over those to morph them into acceptable
package lists for the host arch. Which are later available because the
postinst goes ahead and duplicates all entries in sources.list.
For dpkg-deb, it intercepts “--control” and “--fsys-tarfile”. The latter
does all sorts of pretty things including moving files around (to
/usr/lib32, eg.), changing the Architecture field, and amending the
Depends field.
I realize quite a lot of effort has been put into writing this and to
make sure it works, but as said above, I’m unsure it’s an acceptable
solution to this problem. As an amd64 user, I’d be disgusted to see such
a hack forced down on my system, and disappointed in Debian for
sanctioning such solution.
> 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 [packages
> depending on ia32-lib*] could never transition from unstable to
> testing on [their] own.
Actually they can, because britney can be told that some packages are
available even if they are not in the Packages lists. However, and given
my opinion above, I will refuse to do that unless there’s clear consensus
among the active developers that this is an acceptable solution. Because
of that, opinions welcome.
I’d also be interested in hearing from ftpmaster their thoughts on the
matter. Maybe a less fugly hack can be devised if the need to address
the current ia32-libs mess is really strong.
Mark Hymers has talked about providing a mechanism to ensure source
packages stay on the pool when other stuff has been built from them (eg.
kernel module packages). With this, ia32-libs could become a small
source package containing scripts that would download the necessary
binary packages at build time, and would encode in a header the employed
versions; then, source for those versions would not be removed from the
pool.
And ia32-libs could be easily Bin-NMUed regularly, in order to pick up
the latest libraries from testing. I know downloading stuff in the build
process is not something we want to do, but we have packages with
special needs that do it by design (eg. the installer).
Thoughts?
Cheers,
--
- Are you sure we're good?
- Always.
-- Rory and Lorelai
Reply to: