Hello,

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.

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?

Cheers,
--
Raphaël Hertzog ◈ Debian Developer

Follow my Debian News â–¶ http://RaphaelHertzog.com (English)
▶ http://RaphaelHertzog.fr (Français)


--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110218113118.GA7140@rivendell.home.ouaza.com">ht tp://lists.debian.org/20110218113118.GA7140@rivendell.home.ouaza.com

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.

> 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 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.

Higher-level package managers should detect this and do the needful.
foo_1.0_foreign should be removed as part of the upgrade, solving the
conflict and allowing foo_2.0_all to be configured.

So yeah, that seems ok to me, but I guess you're not convinced or you
wouldn't have asked. What other way do you see this working? Should
dpkg auto-remove multiarch packages when an upgrade to _all is requested?
That seems very inconsistent with dpkg's "do what I say" approach, IMHO.

Cheers,
--
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

On Fri, 18 Feb 2011, Steve Langasek wrote:
> So yeah, that seems ok to me, but I guess you're not convinced or you
> wouldn't have asked. What other way do you see this working? Should
> dpkg auto-remove multiarch packages when an upgrade to _all is requested?
> That seems very inconsistent with dpkg's "do what I say" approach, IMHO.

Well, from the implementer point of view, this behaviour is what works
with the least modification to dpkg. So I'm happy if we can agree that
this is correct.

That said when I wrote my non-regression tests, I wrote them in a way
that checks that you can upgrade a M-A: foreign foo_1.0_<foreign> to
foo_2.0_all (and vice-versa). Because that's what seemed most logical from
a user point of view.

Upgrading multiple M-A: same to a single foo_2.0_all should definitely be
forbidden though. But the opposite foo_1.0_all -> M-A: same
foo_2.0_<foreign> ?

So I wanted to know how other people feel on this issue.

Cheers,
--
Raphaël Hertzog ◈ Debian Developer

Follow my Debian News â–¶ http://RaphaelHertzog.com (English)
▶ http://RaphaelHertzog.fr (Français)


--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110218193705.GA13604@rivendell.home.ouaza.com">h ttp://lists.debian.org/20110218193705.GA13604@rivendell.home.ouaza.com

On Fri, Feb 18, 2011 at 08:37:05PM +0100, Raphael Hertzog wrote:

> Upgrading multiple M-A: same to a single foo_2.0_all should definitely be
> forbidden though. But the opposite foo_1.0_all -> M-A: same
> foo_2.0_<foreign> ?

I think the applicable principle here is KISS. You could allow dpkg to
upgrade foo_1.0_all to foo_2.0_foreign, but *nobody would understand what
dpkg was doing*, and why this case was different than the others.

--
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

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


--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 871v333dby.fsf@frosties.localnet">http://lists.debian.org/871v333dby.fsf@frosties.localnet

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


--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110219221115.GB12618@virgil.dodds.net">http://lists.debian.org/20110219221115.GB12618@virgil.dodds.net

Hi,

On Sat, 19 Feb 2011, Steve Langasek wrote:
> > 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.

That's how apt handles the case, indeed. But it's something that we'd like
to get rid of at some point.

dpkg already has code to ignore conflicts from a package that is marked
as being removed so it would be nice if frontends could use this facility
instead.

(But that's orthogonal to this discussion, I just wanted to point it out)

Cheers,
--
Raphaël Hertzog ◈ Debian Developer

Follow my Debian News â–¶ http://RaphaelHertzog.com (English)
▶ http://RaphaelHertzog.fr (Français)


--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110220075946.GF11855@rivendell.home.ouaza.com">h ttp://lists.debian.org/20110220075946.GF11855@rivendell.home.ouaza.com