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

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

Andreas Barth <aba@not.so.argh.org> writes:

> * Steve Langasek (vorlon@debian.org) [090809 21:04]:
>> The fallback would be to /assume/ they exist, and
>> have each multiarch library package add Conflicts against the expected
>> biarch package name; I don't accept that this is an appropriate burden to
>> impose on individual library maintainers as part of the multiarch
>> implementation, which should otherwise only require a small debian/rules
>> change and a single Multi-Arch: yes field.
>
> Can't that conflicts generation added in some debhelper-rule (same for
> cdbs), which puts away the burden from most maintainers?
>
>
>
> Cheers,
> Andi

Maintainers are burdened with having to Conflicts/Replaces with:

  Package                         Popcon count
  ia32-libs                       7273
  ia32-libs-dev                      1
  ia32-libs-gtk                   4047
  ia32-libs-kde                   ??? ubuntu
  ia32-libs-scim                  ??? ubuntu
  ia32-libs-xulurunner            1408
  ia32-libs-libnspr4              1263
  ia32-libs-libnss3               1257
  ia32-libs-libssh2               1238
  ia32-libs-libidn11              1231
  ia32-libs-libcurl3              1221
  lib32*


On the other hand, assuming that an ia32-apt-get user will keep using
ia32-apt-get, the ia32-libs-tools generated packages will take care of
themself:

1) The generated packages can trivially conflict with the multiarch
packages as soon as dpkg understands the syntax.

2) If ia32-apt-get is used then it sits between the Packages.gz file
being downloaded and it being parsed by apt. It could esily add
Conflicts/Replaces entries in the multiarch packages on the fly the
same way it transforms Packages.gz now. Users would just have to use
ia32-apt-get long enough to replace all ia32-* packages with their
multiarch equivalent.

3) As mentioned in another mail my plan is to mirror package names
multiarch will use them when dpkg/apt support them. The converted
packages, always being a lower version than the input package, are
then natural predecesors of the multiarch packages and apt will just
update it like it updates foo 1.2-3 to foo 1.2-4 now. In effect
ia32-libs-tools will generate multiarch packages on the fly.

4) In recent versions all converted packages have "Provides:
ia32-abi". If need be (all the above are unsatisfactory) the mutliarch
dpkg can conflict with that causing them all to be removed in a single
stroke. Users can then reinstall the multiarch ones without problems.
The ia32-libs* packages can also Conflicts/Replaces: ia32-abi to allow
users to switch between the two methods at will.


I don't believe asking ia32-apt-get users, which are officially all
unstable users, to run "ia32-apt-get update; ia32-apt-get install
ia32-apt-get; ia32-apt-get update; ia32-apt-get dist-upgrade" (or
their frontend of choice) before switching on multiarch in apt/dpkg is
a burden. For most people that will happen naturally anyway.

There is also the issue that it has been around for 1 1/2 years and is
in use by a sizeable group of users already. There is no going back,
only forward.

MfG
        Goswin