Re: How to depend on 32bit libs on amd64? (and what to do with ia32-libs)
Adeodato Simó <dato@net.com.org.es> writes:
> * 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 alternative solution is ia32-archive, which creates a local
repository of converted packages on the users system. No wrappers
needed and no ugly hacks but that comes at the cost of disk space and
the need to configure what packages to convert (converting just
everything would cost too much disk).
The problem how to state the depends remains the same.
>> 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.
Buildds don't have internet access in their build
environment. ia32-libs may not download anything at build time. Plus
rebuilding would give widely unreproducible results.
As for avoiding the source duplication that would be nice.
> 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?
Currently the size makes regular uploads too costly imho. And the
security team is still not supporting ia32-libs. I even did prepare an
security upload for etch last year that they only had to sponsor but
never heard back from the team.
> Cheers,
MfG
Goswin
Reply to: