Re: Bug#535645: Bug #535645: Wrongfull removal of ia32-libs-tools

[Goswin von Brederlow <goswin-v-b@web.de>]

Steve Langasek <vorlon@debian.org> writes:

> On Sat, Aug 08, 2009 at 07:15:13PM -0700, Russ Allbery wrote:
>> Goswin von Brederlow <goswin-v-b@web.de> writes:
>
>> > 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'm not saying this means we should do nothing, just asking to help
>> understand the overall context better:  Does the debate over this package
>> become moot if Debian adopts full multiarch?  In other words, is this a
>> stop-gap solution while waiting for multiarch, or do you see it as having
>> an ongoing purpose even in a multiarch world?
>
> Per <http://lists.debian.org/debian-devel/2009/07/msg00121.html>,
> ia32-apt-get also imposes other obligations on a multiarch implementation,
> which no consensus has been reached on:
>
>   The upgrade path to multiarch is for the multiarch i386 deb to
>   Conflicts/Replaces: <package that contains the same files>. Which
>   means ia32-libs or ia32-libs-gtk for the old system or ia32-<package>
>   for the ia32-apt-get one. And again with ia32-apt-get there is a huge
>   advantage. As packages convert to multiarch they can be droped in
>   ia32-apt-get on a case by case basis and replaced by the multiarch
>   one. Meaning users don't have to wait for and update 200 packages in a
>   single step.
>
> So more than being a stop-gap, I think this tool is actively harmful to the
> rollout of multiarch.
>
> I would vote against any resolution to override the ftp masters' decision to
> remove this package from the archive.

This has also been addressed in ia32-libs-tools since then, or rather
I didn't see the trivial way to do it back then. The ia32-apt-get
mechanism transforms the binary-i386/Packages.gz file between apt
downloading and apt parsing it. Currently it transforms libfoo to
ia32-libfoo in that process. With multiarch packages it would see
libfoo as being multiarchified and just add "Conflicts: ia32-libfoo"
and "Replaces: ia32-libfoo" to its stanza.

So I believe that to be a non-issue.

MfG
        Goswin