Can we do this? [Was: Re: How to tell users that ia32-libs will go away]
- To: debian-release@lists.debian.org
- Subject: Can we do this? [Was: Re: How to tell users that ia32-libs will go away]
- From: Goswin von Brederlow <goswin-v-b@web.de>
- Date: Thu, 23 Feb 2012 15:59:47 +0100
- Message-id: <[🔎] 87boopy4rg.fsf_-_@frosties.localnet>
- In-reply-to: <87wr7vgc2x.fsf@frosties.localnet> (Goswin von Brederlow's message of "Fri, 10 Feb 2012 12:30:30 +0100")
- References: <87ehu4oy6o.fsf@frosties.localnet> <4F33E988.4080102@free.fr> <20120209185255.GC17381@virgil.dodds.net> <87wr7vgc2x.fsf@frosties.localnet>
Goswin von Brederlow <goswin-v-b@web.de> writes:
> Dear ftp-master,
>
> I wonder if the solution below for transitioning ia32-libs to multiarch
> would be OK in regards to DAK and testing transition etc. Any technical
> problems why we couldn't make an exception for the 3 ia32-libs* packages
> for this?
Since ftp-master has not raised any objection ("who stays quiet agrees")
the same question goes to the release team.
Specifically can we set up an exception for ia32-libs to go into testing
(and then stable) with the dependency being unfullfillable on amd64
(without i386 enabled)?
> Steve Langasek <vorlon@debian.org> writes:
>
>> On Thu, Feb 09, 2012 at 04:43:04PM +0100, Thibaut Paumard wrote:
>>> Le 09/02/12 15:53, Goswin von Brederlow a écrit :
>>
>>> > now that a multiarch dpkg has been uploaded to experimental it looks
>>> > like we can finaly get rid of ia32-libs* for wheezy.
>>
>>> > !!!HURAY!!!
>>
>>> > The problem now is the transition:
>>
>>> > 1) multiarch and ia32-libs are incompatible
>>> >[...]
>>> > What this means is that users that want to use multiarch should remove
>>> > ia32-libs (and lib32* really) soonest.
>>
>>> Couldn't you make ia32-libs a meta-package pulling the multiarch version
>>> of the libs it used to include ?
>>
>> This would require something like
>>
>> Depends: libpam0g:i386, libssl098:i386, [...]
>>
>> and this syntax is not yet supported (intentionally, because there's a lot
>> of policy that needs to be put in place before we allow such things).
>>
>> Ubuntu, faced with the same issue, kludged a bit to make upgrades possible.
>>
>> Package: ia32-libs
>> Architecture: amd64
>> Depends: ia32-libs-multiarch
>>
>> Package: ia32-libs-multiarch
>> Architecture: i386
>> Multi-Arch: foreign
>> Depends: libpam0g, [...]
>>
>> This doesn't require us to support :arch syntax for dependencies anywhere
>> yet; it just requires that the i386 arch is enabled via multiarch, and that
>> the package manager is able to resolve the fact that ia32-libs' dependency
>> is satisfied by the only copy of ia32-libs-multiarch available, the i386
>> one.
>>
>> However, this still introduces at least some of the same policy problems -
>> for instance, britney has to be taught that this is ok if you want to be
>> able to migrate this package to testing automatically. And you need a
>> multiarch-capable package manager installed and configured *before* you can
>> upgrade this package, so that requires a two-step upgrade of some variety:
>> either holding ia32-libs back until after the dist-upgrade, or upgrading the
>> package manager before the dist-upgrade.
>
> MfG
> Goswin
Reply to: