Re: [RFC] Multi-arch-enabled command-line interface

[David Kalnischkies <kalnischkies+debian@gmail.com>]

2010/8/13 Goswin von Brederlow <goswin-v-b@web.de>:
> David Kalnischkies <kalnischkies+debian@gmail.com> writes:
>
>> 2010/8/12 Julian Andres Klode <jak@debian.org>:
>>> For read operations (show,showpkg,policy):
>>>        NAME      - Display the package for all architectures
>>>        NAME:ARCH - Display the package for the ARCH architecture
>>
>> Most show* commands for different architectures are pretty boring.
>> The show-entry for apt:i386 and apt:amd64 differs only in the
>> Architecture line. I would expect that show shows me the
>> package i would get by installing "apt"…
>>
>> In APT policy is currently the only one differing and i am not
>> completely sure about that one either…
>
> Currently show shows all versions, not just the one it would
> install. The same should be true for archs.

I personally have the --no-all-versions option activated, but
displaying version 1, 2 and 3 make some sense to me still.
Displaying two or more stanzas for the same version which
are identical expect the Architecture line
(and in a few cases also some Dependency lines) doesn't
in my eyes. If i say "apt-cache show whatever" i want to
see the information for package i will get with "apt-get install whatever".
Beside that it is also a breakage minimizing "feature" as i am
pretty sure scripts will not expect all architectures…


>>> For install:
>>>        NAME      - Install the native candidate (or Architecture: all)
>>>        NAME:ARCH - Install the candidate for ARCH
>>
>> Imagine a package only existing in i386 and your are native amd64.
>> Do you want that the user really worries about the architecture of
>> this package? APT uses "the best" architecture to install
>> (best defined as non-virtual architecture listed at first).
>
> The native arch should have a higher pin than non-native archs by
> default as was present in my patch. That would make a native package the
> candidate if it is awaylable automatically and users can trivially use
> pinning to change the preference for all or individual packages.

To be able to not change the complete infrastructure MultiArch in APT
uses a "little" trick: It handles apt:i386 and apt:amd64 as completely
different packages instead of "only" different versions of the same package.
(Internal) reasons are (just a few, not all):
- dependencies have no architecture information
- the target package of a dependency can't be changed (easily) at runtime
- you can have multiple versions of the same package installed or as
candidate - but you need to for e.g. Multi-Arch: same. They must have the
same version number as defined by spec, but they can be completely different
otherwise ([pre-calculated] dependencies and so on)
- candidate calculation is broken every time i386 lags behind amd64 (or v.v.)
as for installed apt:i386 v1 (500) apt:amd64 v2 (499) will be the candidate…
=> So the pin trick was dropped as not working always.

> Then "NAME" should install the candidate with the highest pin regardless
> of arch.

Still, i like that idea. :) We have for each arch a candidate from which we
could choose the one with the highest pin and if multiple have the same
choose the one which is higher in the architectures list…
Thats why i quoted "best": The election process is discuss-worthy.

>>> For remove and purge:
>>>        NAME      - Remove all packages named NAME
>>>        NAME:ARCH - Remove the package NAME for architecture ARCH
>>
>> I admit that i haven't thought about that before as i am removing to
>> few packages by hand… ;) APT currently chooses again "the best".
>
> Currently the NAME is unique so one can't really say there is any
> choosing. :)

Yeah sure the current sid one doesn't have such a choice,
i referred to the experimental one with multiarch enabled
(i eat my own dogfood all the time so this feels like default for
me already) - and this one already need to make a choice
which package is meant.

For this choice it currently doesn't look at the installation status
of the package, so you will get an "error" if you do
apt-get remove libfoo
in amd64 environment but libfoo:i386 installed (not libfoo:amd64).
That maybe sounds counterintuitive now, but i think it fits better
into the rest of the "system". apt-get install libfoo would install
the libfoo:amd64 package, apt-cache show displays this one,
so remove should act on the same package.
Maybe, if we want to be user-friendly it could display:
"heh, maybe you mean libfoo:i386" as it does with virtual packages
(and as you suggested later).


Best regards,

David Kalnischkies