Raphael Hertzog <hert...@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-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87hayhzplu.fsf@frosties.localnet
