[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Multiarch file overlap summary and proposal

On Fri, Feb 17, 2012 at 19:53, Carsten Hey <carsten@debian.org> wrote:
> * David Kalnischkies [2012-02-17 14:15 +0100]:
>> You generously left out the paragraph describing how APT should
>> detect that the package foo is in fact a library ...
> My impression was that you think very library centric.  All I wrote was
> (in other words), that we should consider non-library packages as much
> as library packages, and I did not write nor implied that libraries
> should be handled in a different way.
>> Is 'apt-get remove foo+' then going to install all foo's or just one?
> "apt-get install g+++" is a weird syntax.

But its a syntax we support since basically ever and comes in handy
if you want to tell APT to not choose a specific alternative
(or disable specific recommends, …) without holds.
aptitude supports a few more of these modifiers (e.g. &) btw.

> The above shows that it seems to depend on the availability of
> foo:native if apt-get remove foo removes foo:foreign.

It's the availability of the native (or for that matter: most preferred arch)
which 'changes' this behavior. As tendra is not available for amd64 its
a pretty fair guess that i386 was meant and - as the result would be an
error otherwise - install it.
It's removed with the same command s/install/remove/.

A similar guess isn't done for removes in case the native is not installed
(but available and foreigns are installed) as it is a destructive command
(beside that it would fail the s/remove/install/ test).
See also the arguments against the
"foo == foo:whatever provided that whatever is unique"
in Raphaels mail in thread [0] mentioned above.

And as i said, its not only about apt-get install/remove.
It would be nice to have an approach usable for the various
commands of apt-mark and apt-cache, too.
(bonus points if it doesn't break usage with dpkg completely)

>  # dpkg -l | awk '$2=="clang"{print}'
>  ii  clang                           3.0-5                 Low-Level ...
>  # dpkg -S bin/clang
>  clang: /usr/bin/clang
>  clang: /usr/bin/clang++
>  # dpkg -r clang
>  dpkg: warning: there's no installed package matching clang

The last one is an inconsistency in what dpkg should do.
If i understood the outcome of thread [1] above right dpkg
doesn't want to arch qualify packages for which only one package
can be meant. I personally think this is misfortune, but so it be.
APT can't do this as while you might have only one installed at a
time you can still jungle with different archs in one apt command
so we need differentiate here.

Long story short, 'apt-get remove clang' fails, yes, but you have
it installed with 'apt-get install clang:i386' so we are at least
consistent (see foo == foo:whatever).
I could have a look at printing a notice through to be nice…

>  # dpkg -l | grep libzookeeper-st2
>  ii  libzookeeper-st2:amd64          3.3.4+dfsg1-3         Single ...
>  ii  libzookeeper-st2:i386           3.3.4+dfsg1-3         Single ...
> Unlike the above dpkg -l output showing the foreign clang package,
> libzookeeper-st2 is shown with the architecture appended.

dpkg prefers users which are specific if they refer to a M-A:same package.
It allows no arch as ~ 'installed' arch, but mostly only for backward-
compatibility as apt/squeeze obviously doesn't know about that new

Best regards

David Kalnischkies

Reply to: