Bug#535645: Bug #535645: Wrongfull removal of ia32-libs-tools
Andreas Barth <aba@not.so.argh.org> writes:
> * Goswin von Brederlow (goswin-v-b@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
Reply to: