[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

How to tell users that ia32-libs will go away


now that a multiarch dpkg has been uploaded to experimental it looks
like we can finaly get rid of ia32-libs* for wheezy.


The problem now is the transition:

1) multiarch and ia32-libs are incompatible

Having multiarch packages and ia32-libs installed will lead to some
confusion. The runtime linker will not be able to differentiate between
multiarch or ia32-libs libs. One of /usr/lib32/ and
/usr/lib/i486-linux-gnu/ will be first in the search path and libs will
be taken from there preferably. As a result binaries might end up with
the wrong version of a library and potentially break. As time goes on
the problem will only get worse.

What this means is that users that want to use multiarch should remove
ia32-libs (and lib32* really) soonest.

2) How to inform the user that ia32-libs is no longer and what to do?

I will do one more upload of ia32-libs to unstable to fix a number of
critical issues that have collected over the last months. I don't intend
to fix anything beyond that and nobody else seems to care enough to
help. Therefore I intend to request removal of ia32-libs from wheezy
shortly before the release.

This gives me the chance to inform testing/unstable users of what is to
come. Get more users to test multiarch as replacement for ia32-libs.

Are there any objections to adding a debconf message to ia32-libs with a
short message and reference to a Debian wiki page on how to transition
to multiarch?

3) What about stable users?

I don't see a way to transition stable users slowly. As said above I
intent to request removal of ia32-libs for wheezy. So there will be no
transition period where both ia32-libs and multiarch will be in stable.

I guess it is then up to the release notes to tell users about multiarch
and how to transition to that from ia32-libs. Hopefully by then the
Debian wiki page will have been filled with lots of information that can
be used to add to the release notes.

4) Should we have some Breaks/Conflicts between multiarch and bi-arch

The libc6:i386 package could Conflicts/Breaks: libc6-i386,
ia32-libs-core and the libc6:amd64 package could Conflicts/Breaks:
libc6-amd64. This would essentially prevent multiarch and bi-arch
packages to be installed in parallel. Enabling multiarch and installing
basically any foreign package would then automatically remove any
bi-arch package.

Given the file conflict on the ld.so between those packages it should be
Conflicts or Breaks+Replaces actually.



Reply to: