Re: [RFC] Multi-arch-enabled command-line interface
David Kalnischkies <kalnischkies+debian@gmail.com> writes:
> 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.
For some notion of broken. It prefers the better version over the better
architecture. But you are right that apt should probably not chnage the
architecture of an installed package on its own.
>> 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 first time installs that should definetly happen.
>>>> 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
I think if you go that way then omitting the architecture should
implicitly mean the native architecture ALL THE TIME. Currently if a
package only exists for armel then :armel can be omited.
It would be inconsistent if this where needed:
apt-get install foo
apt-get remove foo:armel
I.e. picking the arch on install but require it on remove. Currently
that can happen if between install and remove some package adds
"Replaces: foo".
Personally I would prefer apt to pick an arch if the arch is omitted and
on removals consider installed packages only.
MfG
Goswin
Reply to: