Re: Cross-upgrading packages with multiarch packages
On Sat, Feb 19, 2011 at 10:48:49PM +0100, Goswin von Brederlow 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>.
What does the command line for that look like?
> 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.
No, that's what 'dpkg --remove --force-depends' is for, which I believe is
exactly how apt already handles conflicts on upgrade.
Remember that this only applies to the *foreign* arch package being removed
during the upgrade. Nothing that should make the update itself unstable;
and the packages in question, since we're asserting they can be converted
from arch:any to arch:all, probably have very few actual files being removed
from disk by the dpkg --remove foo:foreign.
> 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.
It possibly could be done with a breaks, although breaks is asymmetric and
at the time this was spec'ed out, everyone involved agreed that we wanted
the symmetry of conflicts. (I think this may have been Guillem's idea
originally.) But in any case, I don't see any value in revisiting this
decision until we have some solid experience with the implementation. Just
as Breaks didn't even *exist* for years until we gained experience with
Conflicts, we should start with Conflicts for multiarch and only consider
changing to Breaks semantics when we have empirical evidence that Conflicts
handling is a problem, *and* that Breaks won't cause regressions.
> 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.
For purposes of simplicity of the dpkg implementation, I think it shouldn't.
A robust, consistent, comprehensible dpkg implementation is more important
than transparent handling of upgrade corner cases.
(I certainly did consider this case, even if I didn't write about it
explicitly.)
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
slangasek@ubuntu.com vorlon@debian.org
Reply to: