Re: Multiarch interfaces: print foreign arches, pkgname I/O
On Tue, Dec 13, 2011 at 20:55, Julian Andres Klode <firstname.lastname@example.org> wrote:
> On Tue, Dec 13, 2011 at 09:19:55AM +0100, Guillem Jover wrote:
>> On Mon, 2011-12-12 at 18:14:15 +0100, David Kalnischkies wrote:
>> > Beside that i wonder which --force flag this should be, given that it
>> > removes packages while it was requested to install others.
>> > In a way, the old architecture is disappearing, but there are no
>> > Replaces (not even implicit) in place to allow that and the implicit
>> > Conflicts wouldn't allow a seamless disappearing anyway.
>> > So implementing this sounds for me a bit like black voodoo…
>> This will be treated like a normal upgrade, the only distinction will
>> be that the architecture of the installed package changes, like it
>> currently happens on --force-architecture (but w/o the need of the
>> option), and only one installed instance can present for this to
> And that clashes with the view APT has on the universe; pkg:a and
> pkg:b are distinct packages of a group "pkg". So for that to work
> correctly, APT would need to add some kind of implicit
> Replaces: pkg:other
> to the packages. At least IIRC.
Replaces will not really help (as they are ignored by APT) given that
you never know if it replaces the complete package or "just" a few files.
APT will just do what is actually required by the (implicit) conflicts:
Instruct dpkg to remove pkg:a and install pkg:b. This works as long
as pkg isn't essential like the obvious pkg=dpkg. Every other behavior
is outside the MultiArch Spec and actually involves ignoring it -
given that the implicit multiarch-conflicts would be ignored.
If anyone wants a different behavior, write a Spec (e.g. MultiArchCross) and
get people to implement it. Maybe we will be lucky and in six years
this will be done, in the meantime it would be fabulous if we could
play with the non-cross MultiArch part as crossing essential packages
is just a tiny fraction of a usecase for MultiArch. Thanks.
David Kalnischkies, who still hopes to have foreign packages under
his dependency tree on Christmas 2011…