[Pkg-ia32-libs-maintainers] ia32-lib plans and security support for same

[Goswin von Brederlow]

Florian Weimer <fw at deneb.enyo.de> writes:

> * Goswin von Brederlow:
>
>> Joerg Jaspert <ftpmaster at debian.org> writes:
>>
>>> - The included complete copy of the source *and* the existing i386
>>>   binary is something that is really bad. Yes, we get in trouble if we
>>>   don't include the source for packages on the archive, but it is still
>>>   a *very* strong point against this packaging scheme.
>>>   We (as in ftp-team), but even more the security team are against
>>>   them.
>
> I think from a security support POV, we can get away with it if the
> .debs are not actually built from the included source code.

If we could we wouldn't have the problem. :)

The source is included just to make sure it is available as required
by e.g. the GPL. Without it the source would be missing when the
original package has a different version.

>> I hope you feel that this will simplify matters not just for us but
>> also for you and will allow this package split continue.
>
> I simply lack the necessary network bandwidth to keep the current
> ia32-libs updated.  But for someone with good connectivity, it should be
> relatively straightforward to build periodic roll-up packages.  We
> should figure out why this hasn't happened.  The fundamental problem
> probably lies somewhere else.

I have the bandwith, sort of. It still takes me an hour to upload and
I managed to break mentors.debain.net because the package was too big
to handle. :)

The nice thing with the split is that now I only have to update one of
the many packages. So it is only 1-40MiB.

> (Note that you need to deal with security updates *and*
> stable-proposed-updates, BTW.)

I'm planing to add a cron job that mails every time a package gets
updated. Easy enough to let that scan s-p-u as well. So I'm not
worried there. Unlike security updates a delay in an update to s-p-u
is inconsequential as long as it doesn't miss the point release.

> And what about downloader that build .debs locally, from the i386 .debs?
> Has this approach been considered?  This would sidestep the issue of
> up-to-dateness.

Option 1) /usr/lib/apt/methods/ia32

I can add a sources.list entry like
deb ia32://http://ftp.debian.org/debian sid main

When installing a deb this calls the ia32 method that can do
on-the-fly conversion. Sounds great?

Problem is "apt-get update" downloads Release.gpg, Release and
main/binary-amd64/Packages.bz2. The Packages file has to be generated
from main/binary-i386/Packages.bz2 but with the md5sums replaced with
what the conversion will create. Then the Release file has to be
generated and signed.

So to make this work I have to download every single deb that can
possibly be converted before I can even give apt-get the
"Release.gpg".


Option 2) ia32-archive (part of ia32-libs-tools in svn now)

This has a list of debs the user wants converted and keeps an
up-to-date apt repository in /var/lib/ia32-archive. It comes with a
hook in /etc/apt/apt.conf.d/ so the repository is updated before every
apt-get update call. A cron job is an alternative too that.

This would actualy be the sanest for buildds. The archive doesn't even
have to be on the buildd. It can be hosted anywhere.


Option 3) ia32-apt-get (experimental, proof of concept under way)

apt-get is replaced by a wrapper that actually runs "apt-get -o
Apt::Architecture=amd64 update" and "apt-get -o Apt::Architecture=i386
update" in different directories and merges the resulting index
files. The i386 Packages file is mangled, Release and Release.gpg are
recreated. But the debs are not touched so the md5sum remains.

You get 3 apt configs: /etc/apt/native/sources.list (for amd64 or ia64),
/etc/apt/foreign/sources.list (for i386) and /etc/apt/sources.list
(merged together). By adapting option 1 to this I can probably get rid
of having 3 conffiles. But that is just a thought.

dpkg-deb is replaced by a wrapper that catches i386 debs and converts
them while unpacking them.

The bonus is I can do "dpkg -i libfoo_1.2-3_i386.deb" and it will
install ia32-libfoo on amd64 or ia64.

This might be the most dangerous to adapt to buildds given their mix
of normal system and chroot usage.




All 3 options have 3 big problems:

- Getting buildd support for this isn't trivial.
  Apart from getting the buildds to actually see the debs the
  automatic Build-Depends dep-wait in wanna-build might just not let
  sources get that far. rar, wine, nspluginwraper and the java
  packages wouldn't autobuild anymore.

- Depends on packages not in Debian.
  Since the converted packages never show up in debian anything that
  depends on one of them would (technically) depend on a package not
  in debian. This is not allowed in main. This would hold up the
  testing migration.

- Ugly. Well, ia32-libs is ugly too. Pick your evil. :)

The only clean way out if multiarch. Lets hope for lenny+1.


My goal for lenny is actualy a mixture. First I want to get split
packages into lenny because I know that works. Build-Depends and
Depends (where they are manual) can be adjusted. Meanwhile I keep
working on ia32-archive and ia32-apt-get. Once they are tested and
working packages that are not Build-Depends or Depends can be removed
from lenny. Lenny would only have ia32-* packages where
Build-Depends/Depends require them and use ia32-archive and/or
ia32-apt-get for the rest. That would cut the package count a good
bit.

MfG
        Goswin