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/ [email protected] [email protected] -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
