Andreas Barth <a...@not.so.argh.org> writes: > * Goswin von Brederlow (goswin-...@web.de) [090809 06:44]: >> My plan is that it will be reduced to nothing as stages of multiarch >> get implemented and finaly be removed. But multiarch will need time to >> get there and ia32-apt-get probably will add extra value to it until >> multiarch can enter round 2 after having been around for a full stable >> release cycle. > > Can you please say how you pkan the different stages of multiarch, and > when are they due? Is this plan coordinated with someone (release > team, ftp team, dpkg maintainer, ...)?
I don't think that is really relevant to the question of wether ia32-libs-tools should be in the archive or not. Right now there is no multiarch and right now ia32-libs-tools is a valuable tool for many users. Even if there would be absolutely no plan to support multiarch it would be just like ia32-libs, ia32-libs-gtk, dpkg-cross or apt-cross. But here is the plan: Implementing multiarch involves (among a million other details): - Adding support to libapt to download binary-<arch>/Packages for multiple architectures and extending the sources.list format to include [arch=i386] syntax. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=536029 If this is added then the ia32-apt-get, ia32-aptitude, ia32-synaptic wrappers can stop running multiple instances of apt-get to update the packages lists and use just Apt::Update::Post-Invoke. People can keep the wrappers or create an /etc/apt.conf.d/ia32-apt-get and use the plain versions. - Adding support in libapt / dpkg to support package:arch and allowing libfoo:i386 and libfoo:amd64 to be coinstalled. Doesn't need handling of /usr/share/* nor handling the Multi-Arch field nor all the implicit package relationship magic multiarch involves. If this is added then instead of prefixing packages with ia32- for 32bit packages can be suffixed with :i386 in package relationships. Appropriate Conflicts/Replaces get added by ia32-libs-tools and upgrades will replace all the ia32-* packages with *:i386. A stage 1 multiarch implementation would later simply upgrade libfoo:i386 1.2-3~24 (the ia32-libs-tools version) with libfoo:i386 1.2-3 (the pristine Debian package). I can't imagine how the transition could be any smoother. - Moving libraries from /usr/lib/ to /usr/lib/$(DEB_HOST_GNU_TYPE) in individual packages. If this is done (like experimental wine has just done) then ia32-libs-tools can stop moving files from /usr/lib to /usr/lib32. - Introducing the Multi-Arch field in apt and dpkg. Ia32-libs-tools guesses what the Multi-Arch field should be depending on the package name (rename.list conffile contains patterns) and architecture (arch:all or arch:any). Library packages are then made (move libs from /urs/lib to /usr/lib32) to be coinstallable. "Multi-Arch: same" or "Multi-Arch: foreign" can then be added automatically. - Using the Multi-Arch field in actual packages. Currently ia32-libs-tools has to do some guesswork (patterns in the rename.list conffile and architecture of packages) as to what the Multi-Arch field actually should be. With packages declaring their Multi-Arch type the guessing is replaced by knowledge. The renaming to ia32-foo or foo:i386 becomes more certain. Those don't have to happen in any particular order and could happen one by one, in pairs or all at once. But every time the apt and dpkg maintainers add support for any one of the above some hack in ia32-libs-tools can go away. Once Stage1 of multiarch (as per the Ubuntu proposal) is completed, and that is a release goal for squeeze, ia32-libs-tools will only have to handle packages that didn't multiarchify in time for squeeze (and there will certainly be some left) and -dev and -dbg packages that need Stage2 of multiarch (which requires a stable release cycle). When all packages (or enough that the difference doesn't matter) are multiarchified and Stage2 has been completed then ia32-libs-tools will have nothing left to do. All its features will be supported directly by multiarch. The package becomes a NOP and obsolete. As far as I'm concerned coordination will be through the BTS when I write a patch for something, which means coordinated with the respective maintainer. Or through the ML or irc when a maintainer has a question about ia32-libs-tools. I'm not sure what the release team or ftp team would have to do with ia32-libs-tools developement. Whenever, however, by whomever multiarch will be implemented in apt, dpkg and individual packages ia32-libs-tools can take advantage of it. > Also, is "multiarch" (Goswin) the same as "multiarch" (dpkg)? Make that "multiarch" (Tollef) and "multiarch" (Ubuntu). The difference between the old and the new proposal is superficial. The part that affects ia32-libs-tools is that "Multi-Arch: yes|no|unset" became "Multi-Arch: same|foreign|unset". From a coding point of view it really makes no difference which of the two will be used and whatever dpkg/apt will use I will use. MfG Goswin -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org