Bug#535645: Bug #535645: Wrongfull removal of ia32-libs-tools
Dear CTTE,
I'm writing to you in the hope that you can facilitate resolving a
grievance I have with Joerg Jaspert in his roles as ftp-master and his
decision to remove ia32-libs-tools in the name of "The Project".
I started writing ia32-libs-tools 1 1/2 years ago based on my work as
ia32-libs maintainer and job experience with running Debian as Bi-Arch
on amd64. Joerg himself encouraged the developement of ia32-libs-tools
in the REJECTED mail of ia32-alsa-lib (see [1]) and while discussing
on irc. ia32-libs-tools has been in Debian for all but the initial
delay of packaing and NEW processing and has steadily improved to the
fully functional solution it is now.
According to popcon ia32-libs-tools has about 700 users and
ia32-apt-get about 500 (numbers now falling) and the users are now
left out in the cold with an inferior solution (ia32-libs) that only
covers a fraction of the features ia32-libs-tools provides (see
Background Information below). Rene Engelhard even requested a
backport to Lenny.
Ia32-libs-tools (all binary packages it builds) does not divert any
files of other packages, does not conflict/replace with any other
packages and does not interfere with the functionality of any other
packages even if installed. Specifically ia32-apt-get does not
interfere with the package management in any way unless the user
specifically invokes one of the ia32-... binaries. And even then
ia32-apt-get does not touch any of the internals of apt or dpkg. There
is no risk of the package management system getting broken.
There is also no (more) risk of 64bit packages unexpectetly being
upgraded to 32bit packages of a higher version. The existing package
had a debconfig option defaulting against this for some time and the
svn version has a even stronger protection against this. It is still
configurable and if a user wants to use a 32bit bash (or whatever) on
amd64 then he can configure that explicitly and it will work.
In short all the complaints raised in the flame fest on debian-devel
[2] have been addressed and removed from ia32-libs-tools. So I see no
reason "The Project" could have for removing ia32-libs-tools.
The source is fully licenced under GPL version 2 and all its bugs are
pending or wishlist like. None of the pending ones are above
important.
All the information I have about the removal is a conversation on IRC
and the removals.txt on ftp-master:
----------------------------------------------------------------------
14:25 < mrvn> Ganneff: ahh, you are awake. So will you accept ia32-libs-tools
in its benign form it is now?
14:25 < Ganneff> *I* will not.
14:25 < mrvn> Ganneff: may I ask why?
14:26 < GyrosGeier> Ganneff, are there people left who can accept it and who
might?
14:26 < GyrosGeier> (hypothetically speaking)
*silence*
----------------------------------------------------------------------
http://ftp-master.debian.org/removals.txt
=========================================================================
[Date: Tue, 04 Aug 2009 21:50:16 +0000] [ftpmaster: Joerg Jaspert]
Removed the following packages from unstable:
ia32-apt-get | 22 | all
ia32-archive | 22 | all
ia32-libs-tools | 22 | source, amd64, i386, ia64
Closed bugs: 535645
------------------- Reason -------------------
RoThe Project; Most idiotic breakage ever.
----------------------------------------------
=========================================================================
Please help me understand why Joerg just removed my package and
hopefully revert that decision.
What I'm asking for is that ia32-libs-tools is allowed to co-exist
with ia32-libs and ia32-libs-gtk as it has been for the year before
Jun 2009.
I'm not asking for ia32-libs or ia32-libs-gtk to be replaced. The only
reason ia32-libs-tools took them over was that ia32-libs was
unmaintainable, uninstallable and unmaintained for a year and as the
then maintainers we decided to abandon it. ia32-libs and ia32-libs-gtk
have a new maintainer now so they are his problem.
MfG
Goswin
======================================================================
Background information
----------------------
After maintaining the ia32-libs packages for some time the
pkg-ia32-libs team came to the conclusion that there must be a better
way to do this. ia32-libs is fragile, needs constant work and uploads
and the sheer size makes frequently uploading new versions a problem
for the maintainer and the mirror network. There also is code (and
more importantly bugs) duplication between ia32-libs and ia32-libs-gtk
in Debian, ia32-libs-kde and ia32-libs-scim in Ubuntu and several more
ia32-libs-* packages build by users. So ia32-libs-tools was born.
ia32-libs-tools took the common elements of all the ia32-libs*
packages, converting an i386 debian package for use on amd64, and put
it in a tool anyone can Build-Depend on. So there is only one place
where bugs have to be fixed or features added.
The reason ia32-libs is fragile and needs constant watching is that
dependencies, conflicts, breaks are not considered for packages
included in ia32-libs. Every time a library changes its soname the
source breaks on update. Given that the sheer size was also a huge
problem the next step was splitting ia32-libs into multiple packages,
one package per source package that gets converted (95 of them,
*juck*), one binary package per binary package that gets
converted. That way all the existing package relationships could be
preserved and small individual packages could be uploaded when the
i386 package changes. This was rejected by ftp-master (see [1]).
In the REJECTED mail Joerg Jasper wrote:
| - How about you do not provide the ia32-foo packages yourself, but leave
| that to the maintainers? Just provide the tools to *easily* create
| them at build time. That would be the best way to go. It would enable
| basically every package (where it makes sense) to have an ia32
| version, do not double the source code needlessly, etc. Win win.
That is exactly what ia32-libs-tools provides. So in a way Joerg
himself suggested writing ia32-libs-tools even if that was after the
fact that I wrote it.
Unfortunately the DAK and wanna-build do not allow uploading a package
building libfoo_i386.deb, lib32foo_amd64.deb, lib32foo_ia64.deb on
i386, libfoo_amd64.deb on amd64 and libfoo_ia64.deb on ia64. So while
the tool would allow that the infrastructure does not. So creation at
build time is not possible.
Discussing this on irc resulted in the following points being made:
- The conversion process is completly automatic.
- Having converted debs in the archive is a huge waste of space.
- The conversion can be done on the users system just as well as
during build time.
- Converting packages that already exist in the archive as needed by
the user removes all the problems of missing security fixes, missing
libraries, outdated versions, source/binary duplication, space and
bandwith wasteage.
>From that ia32-archive and ia32-apt-get were born.
Ia32-archive creates a local repository of converted packages that can
be used directly, exported via http, ftp or nfs or used to build CD
images that include 32bit support for amd64. Converting all the
packages included in ia32-libs and ia32-libs-gtk takes about 800MB
disk space though. 800MB that are completly wasted if the converted
packages are only for local use.
ia32-apt-get takes the process one step further doing a complete
on-the-fly conversion of packages as they are installed. That means
that if the user asks ia32-apt-get/ia32-aptitude to install
ia32-libfoo (32bit libfoo) it fetches the libfoo_i386.deb, converts
the control.tar.gz and data.tar.gz during unpacking and removes the
tempfiles when done. The only space required is enough temporary space
to unpack each package.
ia32-apt-get provides the following tools:
ia32-apt-get
ia32-aptitude
ia32-apt-cache
ia32-dpkg
ia32-dpkg-deb
All of them simple wrapper scripts that run the existing tools and do
some extra processing before or after the existing tool or just pass
an extra option or two.
Feature comparison:
ia32-libs-tools | ia32-libs
----------------------------------------| ------------------------------
Source: 69311 Bytes | 363171098 Bytes ia32-libs
| 191042473 Bytes ia32-libs-gtk
|
Binary: 46142 Bytes ia32-libs-tools | 29003858 Bytes ia32-libs
18598 Bytes ia32-apt-get | 12168602 Bytes ia32-libs-gtk
11620 Bytes ia32-archive |
|
Suports:3975 libraries | 112+32 libraries
315 binaries |
250+ tested and in use |
|
General:Honors Depends, Conflicts, | Ignores them all
Replaces, Breaks, Pre-Depends, |
Provides |
|
Packages shlibs file converted | Manual shlibs file with manual
automatically preserving the | versioning
version requirements |
|
Instant (security) updates | Needs manual intervention and
for libraries | seperate upload for updates
|
Allows installing i386 debs | Needs repackaging of debs
with full package relationship |
checking |
|
Allows installing debs directly | Repacking means redistribution,
from 3rd party apt repositories | not always legal to do so
Example: skype | Example: skype
|
Allows package maintainers to | Special cases need to be added
provide conversion hooks for | in ia32-libs source by its
special cases | maintainer
|
Allows bit by bit conversion to | No upgrade path to multiarch.
true multiarch as soon as | User needs to purge ia32-libs
support is added to apt, dpkg | and all it reverse depends and
and packages themself. Becomes | reinstall software under
less and less hackish the more | multiarch. Mixtures will lead
multiarch is implemented | to random version mismatches.
======================================================================
[1] http://lists.alioth.debian.org/pipermail/pkg-ia32-libs-maintainers/2008-April/000028.html
[2] http://lists.debian.org/debian-devel/2009/06/msg00902.html
Reply to: