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 -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org