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

Re: multiarch conversion for packages with lib32* packages

Sven Joachim <svenjoac@gmx.de> writes:

> On 2012-03-24 10:50 +0100, Adam Borowski wrote:
>> On Sat, Mar 24, 2012 at 09:48:58AM +0100, Sven Joachim wrote:
>>> On 2012-03-24 04:04 +0100, Jay Berkenbilt wrote:
>>> > One issue not covered is what to do if your package already builds
>>> > 32-bit libraries on a 64-bit system by building 32-bit explicitly and
>>> > packaging as lib32whatever.
>>> The lib32* packages need to built as long as they have reverse (build)
>>> dependencies.  I suppose most of them should go away in the long term,
>>> but this is not going to happen in wheezy.
>> All of lib32icu's rdepends seem to have already dropped *32* builds, so
>> it can be removed right now.
> Oh, indeed.  Somehow I assumed that ia32-libs would build-depend on
> lib32icu-dev, but it doesn't.
> Cheers,
>        Sven

Ia32-libs does not compile/link anything so it has no build-depends on
the -dev packages. And the plan is still to not have ia32-libs in

FYI: Since I have recieved no objections from ftp-master nor the release
team the plan for ia32-libs now looks as follows:

Ia32-libs becomes a transitional package depending on ia32-libs-i386.
ia32-libs-i386 is a new transitional package with architecture i386 that
depends on all the 32bit libs that used to be in ia32-libs.

Package: ia32-libs
Architecture: amd64 ia64
Depends: ia32-libs-i386
Description: ia32-libs transitional package

Package: ia32-libs-i386
Architecture: i386
Depends: libacl1 (>= ver), libaio1 (>= ver), libartsc0 (>= ver), ...
Conflicts: ia32-libs (<< ver)
Description: ia32-libs-i386 transitional package

That means that ia32-libs in amd64 alone will be uninstallable and users
will have to enable multiarch before they can install or upgrade
ia32-libs. But other than that the upgrade should be smooth.

It makes sense to provide this upgrade mechanism for ia32-libs as it has
reverse depends that aren't in Debian. It probably doesn't make sense
for individual lib32 package to do the same. Lib32 packages can normaly
be dropped when they have no more reverse depends or build-depends.


Reply to: