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

[Goswin von Brederlow]

Hi,

FTP-master asked me on irc to get permission from you (debian-security)
for splitting up ia32-libs into multiple source packages before going
any further.

The ia32-libs package provides 32bit i486 legacy support for amd64 and
ia64 so that users can run software that is only available in
32bit. Among others this includes rar, wine, acrobat reader, mplayer
with windows dlls (sometimes you still need those), wine, google
earth, skipe, znes. According to popcon 94% of the amd64/ia64 users
have ia32-libs installed so the demand for 32bit support is still
high.

We, the ia32-libs team, plan to split up ia32-libs into multiple
source packages because it has become too big to keep track of it all.

Too name some numbers we currently have:

ia32-libs contains 116 debs from 106 sources and ia32-libs-gtk
contains 19 debs from 15 sources and more have been requested to
support additional software. In total this makes 440MiB:

-rw-r--r-- 1 mrvn mrvn  499 Apr 25 02:12 ia32-libs_2.4.dsc
-rw-r--r-- 1 mrvn mrvn 319M Apr 25 02:12 ia32-libs_2.4.tar.gz
-rw-r--r-- 1 mrvn mrvn  28M Apr 25 02:20 ia32-libs_2.4_amd64.deb
-rw-r--r-- 1 mrvn mrvn  32M Apr 25 02:13 ia32-libs_2.4_ia64.deb
-rw-r--r-- 1 mrvn mrvn 2.6M Apr 25 02:13 ia32-libs-dev_2.4_ia64.deb
-rw-r--r-- 1 mrvn mrvn  671 Apr 24 15:59 ia32-libs-gtk_2.2.dsc
-rw-r--r-- 1 mrvn mrvn  50M Apr 24 15:58 ia32-libs-gtk_2.2.tar.gz
-rw-r--r-- 1 mrvn mrvn 4.2M Apr 24 15:58 ia32-libs-gtk_2.2_amd64.deb
-rw-r--r-- 1 mrvn mrvn 4.2M Apr 28 01:43 ia32-libs-gtk_2.2_ia64.deb

There is currently (for Lenny at least) no way around having dummy
packages that contain source and precompiled debs and we have to live
with that ugliness for now. This mail isn't about that.

This mail is about how many dummy packages we have. Our plan is to
have one dummy package per source package. The dummy package have a
"ia32-" prefix before their original name to keep the namespaces
separate. The depends, provides, replaces, conflicts Fields as well as
the shlibs and symbols files are adjusted to match.

Advantages:
- trivial to check if the ia32-* package is up to date
- small packages allowing for a quick update/test/upload cycle
- we can keep in sync with unstable and testing
- no 440MiB upload to update a 1MiB library
- correct dependencies safeguarding the testing transition and updates
- bug-reports go to the individual package and not all pile onto
  ia32-libs
- maintainer, if willing, can maintain the ia32-libfoo package
  themself ensuring simultaneous updates

Disadvantages:
- 120 source packages instead of 2 huge ones



FTP-master rejected the first upload of the split packages saying among
other things:

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.

and quotes from a mail he got:

> 4/ Hard to handle for security team
>
> Those packages are not built from sources. This make them hard to handle
> for the security team.

One goal of the split is to actually simplify the handling. Currently
all libs are combined in ia32-libs and ia32-libs-gtk and even noticing
if any of them is affected by a maintainer or security upload is a
problem.

With the split packages there is a simple 1:1 mapping of the name so
it is trivial to check if ia32-foo exists when foo is updated. Lets
say zlib has a security upload:

rmadison ia32-zlib
 ia32-zlib | 1:1.2.3.3.dfsg-12+5 |      unstable | source

After seeing that ia32-zlib exists there are 2 ways to update the
package. First you download the source, unpack it and go into the
directory. Then you

a) put the security repository into /etc/ia32-libs-tools/sources.list
   run 'debian/rules update' to fetch the latest source and debs
   (debian/changelog will be recreated from the security upload so it
   already has all the right info)

or

b) replace *deb, *dsc, *diff.gz and *.tar.gz with the new files
   add changelog entry with new version

and finally you build the package using 'dpkg-buildpackage -aia64' or
'dpkg-buildpackage -aamd64' (if you aren't on one of those archs
anyway).



I hope you feel that this will simplify matters not just for us but
also for you and will allow this package split continue.

Hope to hear from you soon,
        Goswin