dpkg behavior while changing a foreign package from arch:any to arch:all (and v.v.)
 

Hi list of dpkg-glory,


Sometimes packages change their arch from arch:any to arch:all (or v.v.).
This used to be no problem for packages where any was the native arch and
this is still the case, but if it is a foreign arch dpkg refuses to install
the new arch:all version with the following error message:
(assuming we are on amd64 and pkg-a:i386 was installed)

dpkg: error processing pkg-a_2_all.deb (--install):
pkg-a 2 (Multi-Arch: no) is not co-installable with pkg-a:i386 1 (Multi-Arch:
no) which is currently installed

If we flip from arch:all to arch:any the error message is similar:

pkg-a:i386 3 (Multi-Arch: no) is not co-installable with pkg-a:all 2 (Multi-
Arch: no) which is currently installed

(in the first message the :all is omitted from the error message and in
the second it is present, so you might want to make that consistent)

Now, pkg-a:all 2 is not really co-installable with pkg-a:amd64 1 either,
but dpkg happily applies the change in such a context as an "upgrade".


Attached is a small script showing the issue. It's basically an enormously
stripped down version of an APT testcase in case you wonder how I was hit
by the bug (the real test works with an apt configured to have i386 as native,
while my machine on which i run this is in reality amd64, creating something
similar to a cross-grade situation.)


I am not sure through if this is really a bug in dpkg, given that arch:all is
to be interpreted as arch:native in multiarch, so on an amd64 system a
flip from arch:amd64 to arch:all is not really a flip (and therefore works)
while arch:i386 to arch:all is not (and therefore doesn't work).
So this might be very well the intended behavior and not a bug.

It just has interesting consequences for cross-grades and similar cases
in which apt has a different native architecture than dpkg and
it is hard to solve on APT side as it requires in extreme cases that in the
middle of an upgrade the installation actions and there sequence must be
recalculated as dpkg has changed it's architecture in the meantime…


Somehow I get the impression it would be good to have an option in dpkg
to tell dpkg what it should consider as "native" architecture similar to
APT::Architecture to easily solve these kind of communication problems.


Best regards

David Kalnischkies

P.S.: Yes, this was started as a bugreport, but half way though i figured
that's a bit too esoteric and with too many question marks to deserve a #.

dpkg behavior while changing a foreign package from arch:any to arch:all (and v.v.)
 

On Fri, 10 Feb 2012, David Kalnischkies wrote:
> I am not sure through if this is really a bug in dpkg, given that arch:all is
> to be interpreted as arch:native in multiarch, so on an amd64 system a
> flip from arch:amd64 to arch:all is not really a flip (and therefore works)
> while arch:i386 to arch:all is not (and therefore doesn't work).
> So this might be very well the intended behavior and not a bug.

At the very least it was coded that way and the test suite ensures that
this is the case:
# M-A: $* / Upgrade from arch: any-foreign -> all
$(DPKG_INSTALL) pkg-ma-$*_1.0_$(FOREIGN_ARCH).deb
! $(DPKG_INSTALL) pkg-ma-$*_1.0_all.deb
$(call pkg_is_installed,pkg-ma-$*:$(FOREIGN_ARCH))
$(call pkg_is_not_installed,pkg-ma-$*)
$(DPKG_PURGE) pkg-ma-$*:$(FOREIGN_ARCH)
[...]
# M-A: $* / Upgrade from arch: all -> any-foreign
$(DPKG_INSTALL) pkg-ma-$*_1.0_all.deb
! $(DPKG_INSTALL) pkg-ma-$*_1.0_$(FOREIGN_ARCH).deb
$(call pkg_is_not_installed,pkg-ma-$*:$(FOREIGN_ARCH))
$(call pkg_is_installed,pkg-ma-$*)
$(DPKG_PURGE) pkg-ma-$*

The reasoning is precisely the one you gave. It's also coherent
with the current impossibility to cross-grade an "Architecture: any /
Multi-Arch: foreign/no" package from native to foreign and vice-versa.

This is just one reason more that we have to change this at some point
to properly support cross-grades from one arch to the other.

> Somehow I get the impression it would be good to have an option in dpkg
> to tell dpkg what it should consider as "native" architecture similar to
> APT::Architecture to easily solve these kind of communication problems.

Hum, I had not thought of that. It could also be useful to use the host's
dpkg in a chroot of a foreign architecture. Or to use a foreign dpkg for
some reasons (perf? availability?) and still assume the system is running
some other arch by default.

Cheers,
--
Raphaël Hertzog ◈ Debian Developer

Pre-order a copy of the Debian Administrator's Handbook and help
liberate it: http://debian-handbook.info/liberation/


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

dpkg behavior while changing a foreign package from arch:any to arch:all (and v.v.)
 

On Fri, 2012-02-10 at 01:56:02 +0100, David Kalnischkies wrote:
> Sometimes packages change their arch from arch:any to arch:all (or v.v.).
> This used to be no problem for packages where any was the native arch and
> this is still the case, but if it is a foreign arch dpkg refuses to install
> the new arch:all version with the following error message:
> (assuming we are on amd64 and pkg-a:i386 was installed)

Yes, as discussed previously on the list this is a current defficiency
of the implementation. I've been reworking the code to support this as
part of the needed changes for the correct new package input on the
command line.

thanks,
guillem


--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20120214124121.GA22113@gaara.hadrons.org">http://lists.debian.org/20120214124121.GA22113@gaara.hadrons.org

dpkg behavior while changing a foreign package from arch:any to arch:all (and v.v.)
 

Raphael Hertzog <hertzog@debian.org> writes:

> On Fri, 10 Feb 2012, David Kalnischkies wrote:
>> I am not sure through if this is really a bug in dpkg, given that arch:all is
>> to be interpreted as arch:native in multiarch, so on an amd64 system a
>> flip from arch:amd64 to arch:all is not really a flip (and therefore works)
>> while arch:i386 to arch:all is not (and therefore doesn't work).
>> So this might be very well the intended behavior and not a bug.
>
> At the very least it was coded that way and the test suite ensures that
> this is the case:
> # M-A: $* / Upgrade from arch: any-foreign -> all
> $(DPKG_INSTALL) pkg-ma-$*_1.0_$(FOREIGN_ARCH).deb
> ! $(DPKG_INSTALL) pkg-ma-$*_1.0_all.deb
> $(call pkg_is_installed,pkg-ma-$*:$(FOREIGN_ARCH))
> $(call pkg_is_not_installed,pkg-ma-$*)
> $(DPKG_PURGE) pkg-ma-$*:$(FOREIGN_ARCH)
> [...]
> # M-A: $* / Upgrade from arch: all -> any-foreign
> $(DPKG_INSTALL) pkg-ma-$*_1.0_all.deb
> ! $(DPKG_INSTALL) pkg-ma-$*_1.0_$(FOREIGN_ARCH).deb
> $(call pkg_is_not_installed,pkg-ma-$*:$(FOREIGN_ARCH))
> $(call pkg_is_installed,pkg-ma-$*)
> $(DPKG_PURGE) pkg-ma-$*
>
> The reasoning is precisely the one you gave. It's also coherent
> with the current impossibility to cross-grade an "Architecture: any /
> Multi-Arch: foreign/no" package from native to foreign and vice-versa.
>
> This is just one reason more that we have to change this at some point
> to properly support cross-grades from one arch to the other.
>
>> Somehow I get the impression it would be good to have an option in dpkg
>> to tell dpkg what it should consider as "native" architecture similar to
>> APT::Architecture to easily solve these kind of communication problems.
>
> Hum, I had not thought of that. It could also be useful to use the host's
> dpkg in a chroot of a foreign architecture. Or to use a foreign dpkg for
> some reasons (perf? availability?) and still assume the system is running
> some other arch by default.
>
> Cheers,

Don't forget the case of a package rename:

A:native -> B_old:all (metapackage) -> B_new:native (M-A:same)

Without the assumption of all == native dpkg could not ensure such a
renamed package installs the right version.


The multiarch specs [1] say the following:

Dependencies involving Architecture: all packages

Pre-multiarch, architecture-dependent packages may depend on
Architecture: all packages and assume that the transitive
dependencies will be resolved using packages of the same
architecture or other packages that are Architecture: all. To avoid
breaking this assumption, Architecture: all packages will, at least
initially, be treated as equivalent to packages of the native
architecture for all dependency resolution. This means that for an
Architecture: all package to satisfy the dependencies of a
foreign-architecture package, it must be marked Multi-Arch: foreign
or Multi-Arch: allowed.

Imho this should also affect the implicit foo:foreign <-> foo:all
relationships. A foo:all (M-A:foreign/allowed) package should be
considered an upgrade to foo:foreign while (M-A:none) should not to
preserve existing behaviour. That way maintainers could declare wether a
package has become architecture independent or is a metapackage for a
rename.

So my question is: Does the arch:all package in question have a
Multi-Arch field? And does dpkg take this into account?

MfG
Goswin

1) https://wiki.ubuntu.com/MultiarchSpec


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