Re: Cross-upgrading packages with multiarch packages
Steve Langasek <vorlon@debian.org> writes:
> On Fri, Feb 18, 2011 at 12:31:18PM +0100, Raphael Hertzog wrote:
>
>> I'd like to seek feedback about what kind of upgrades dpkg should support
>> with multi-arch packages.
>
>> dpkg treats foo:native and foo:all like the same package and it's thus
>> possible to upgrade foo_1.0_all to foo_2.0_<native> and vice-versa.
>
>> However if you have installed foo_1.0_<foreign>, you can't upgrade that
>> package to foo_2.0_all (and vice-versa). Same goes for foo_1.0_<foreign1> to
>> foo_1.0_<foreign2> (provided they are not multi-arch: same, otherwise they
>> could coexist). You have to remove the conflicting package first and
>> reinstall afterwards.
I hope you mean that one has to remove the foo_1.0_<foreign> /
foo_1.0_<foreign1> in the same dpkg call as adding foo_2.0_all /
foo_1.0_<foreign2>. If this needs 2 dpkg calls, one for removing, one
for reinstalling then I'm flat out against it. That would harm all the
reverse depends and cause significant blockage on upgrades.
Maybe this could be done like breaks instead of like conflicts. The
frontend has to deconfigure the old packages before installing the new
ones and eventually it has to remove the old packages. That might make
upgrades easier and prevent deadlocks where packages need to be
temporarily removed.
>> In a similar vein, if you have several instances of the same package
>> (Multi-Arch: same, say foo_1.0_<native> and foo_1.0_<foreign>), you can't
>> install foo_2.0_all because it's in conflict with foo_1.0_<foreign>.
>
>> Is this behaviour what we want?
I wouldn't say it is what we wan't. But it is something we can live
with. Frontends can handle the finer details.
> I think that actually sounds entirely reasonable. If you have
> foo_1.0_native, foo_1.0_foreign installed, and you try to install
> foo_2.0_all, which package is it an upgrade of? I don't think it makes
> sense from dpkg's POV to be a simultaneous upgrade of *both* packages. So
> it's an upgrade of foo_1.0_native, and should be handled the same way as you
> would handle an attempt to upgrade to foo_2.0_native without also upgrading
> to foo_2.0_foreign.
A foo_2.0_all Multi-Arch:foreign package fullfills the depends for any
architectures. So logically it does represent an upgrade of *both*
foo_1.0_native and foo_1.0_foreign. I think dpkg should handle it that
way, extending the existing behaviour with nativ -> all upgrades to
mutiarch.
On the other hand foo_2.0_all Multi-Arch:none only fullfills the depends
for the native architecture and therefor should only upgrade
foo_1.0_native and complain about foo_1.0_foreign.
Similary with Multi-Arch: foreign the foo_1.0_<foreign1> and
foo_1.0_<foreign2> are equivalent. It would make sense for dpkg to allow
a plain "dpkg -i foo_1.0_<foreign2>.deb" to work and replace
foo_1.0_<foreign1>.
But it isn't essential to getting multiarch working. If it is simpler to
not do this now then lets leave it to the frontends for now.
Futher there is one case you haven't considered. Say you have only
foo_1.0_foreign installed. Should foo_2.0_all Multi-Arch:foreign be
considered an upgrade? I think so.
MfG
Goswin
Reply to: