Re: Multiarch file overlap summary and proposal

[Goswin von Brederlow <goswin-v-b@web.de>]

Russ Allbery <rra@debian.org> writes:

> David Kalnischkies <kalnischkies@gmail.com> writes:
>> On Thu, Feb 16, 2012 at 00:39, Russ Allbery <rra@debian.org> wrote:
>
>>> Actually, why would that be the behavior? Â Why would dpkg --purge foo
>>> not just remove foo for all architectures for which it's installed, and
>>> require that if you want to remove only a specific architecture you
>>> then use the expanded syntax?
>
>> We (as in APT team and dpkg team) had a lot of discussions about that,
>> see for starters (there a properly more in between the 10 monthsâ?¦)
>> [0] http://lists.debian.org/debian-dpkg/2011/01/msg00046.html
>> [1] http://lists.debian.org/debian-dpkg/2011/12/msg00005.html
>
>> In short, i think the biggest counter is that it feels unintuitive to
>> install a library (in native arch) with e.g. "apt-get install libfoo"
>> while you have to be specific at removal to avoid nuking 'unrelated'
>> packages with "apt-get remove libfoo".
>
> Ah, hm... I suppose that's a good point, although honestly I wouldn't mind
> having apt-get remove libfoo remove all instances of libfoo that are
> installed.  I think that would be quite reasonable behavior, and don't
> find it particularly unintuitive.
>
> I agree that it's asymmetric.  apt-get install libfoo means libfoo:native,
> but apt-get remove libfoo means libfoo:*.  And asymmetric is bad, all
> things being equal.  But I think this may be one place where asymmetric is
> still the right thing to do; I would argue that it means you're
> implementing the most common operation in both cases.  apt-get install
> libfoo generally means "give me a native libfoo" since non-native libfoo
> is going to be an unusual case, and apt-get remove libfoo generally means
> "I have no more interest in libfoo, make it go away."  I think that people
> who want to get rid of one architecture of libfoo but keep the other are
> already going to be thinking about architectures, and it's natural to ask
> them to qualify their request.

In another thread we discussed the problem with plugins (e.g. input
methods for chinese/japanese) and LD_PRELOAD (e.g. fakeroot) using
stuff. For those packages it would be great if

    apt-get install plugin

would install all architectures of the package (for various values of
all :). This would add asymetry in that apt-get install libfoo would
sometimes mean libfoo:native and sometimes libfoo:*. Having apt-get
install libfoo:* for anything M-A:same would make it more symetric in
that case.

"apt-get install libfoo" generaly means "please upgrade libfoo to the
latest version". That should be "apt-get upgrade libfoo" which doesn't
yet exists. Libraries should be pulled in from binaries and not
installed manually so I wouldn't give that case much weight.

Instead concentrate on the more usefull cases:

    apt-get install plugin binary libfoo-dev bindings-for-some-interpreter

Plugins will be M-A:same and depend on something M-A:same. They will
have some other indication (to be implemented) that they are
plugins. Libfoo-dev will be M-A:same. Binaries will be M-A:foreign.
Bindings will be M-A:same but depends on something M-A:allowed.

Now think what would be most usefull for those cases.

MfG
        Goswin