Re: Multiarch file overlap summary and proposal
On Thu, Feb 16, 2012 at 09:26, Goswin von Brederlow <goswin-v-b@web.de> wrote:
> 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.
But M-A:same will end-up on dev-packages as well, and these are quiet
likely to be installed manually. And in the end are libraries more often
installed by hand then they are removed - think e.g. of the binary
distribution of certain applications (aka mostly games).
I need libfoo for my new amd64 game so i install it. Later i remove the
game and remember to remove libfoo with it also. I just forgot that i have
a i386 game i play from time to time which requires libfoo:i386 which is
killed by that, too. That i haven't packaged my games is misfortune, but
we are talking about real-world usage here…
Also, in some distant future we might be able to co-install binaries.
It's easy to think of M-A:same just as libraries but i personally think that
this is an unnecessary mental limitation and just exists because it is
currently the (mostly imaginative) case.
And it seems like you assume apt-get and co are only used by humans.
In fact i think it is at least equally common used in scripts, usually with -y
to e.g. remove obsolete packages. I can't wait for the resulting shitstorm…
(btw, you know that 'apt-get purge foo+' is possible, right?
Which behavior would you expect? The same as 'apt-get install foo' ?)
The "same-as" thing in the plugin thread just smells like poor-man's
conditional dependency - and it's trying to solve something which isn't
solvable on that level: Just because i have armel packages installed on my
system doesn't mean that i am going to execute an armel binary.
Cross-building for example will install libc6:armel for me, but i am still
not even close to be interested in libfakeroot:armel.
To get libfakeroot:armel on the system is the responsibility of whatever tool
helps the administrator to setup an foreign armel system on his host,
which is his brain if (s)he chooses to setup it by hand with apt-get.
It's comparable with the dependency grouping for xul-applications:
The user has a variety of usecases to choose from but all these usecases
include the same apt-get command. Which usecase is the most popular
is not really measurable and even if it would it changes over time, but the
behavior of the apt-* tools is expected to be stable at the same time.
I was flamed to death for smaller (and more logical) changes already like
having a non-zero exit in case of apt-cache show virtual-pkg (which in the
end needed to be reverted because of all the breakage it caused).
I guess i am just to weak to release an APT3 and tell the users to fuck off…
(or APT4 - as this is not intended to be an offense against the good work the
various desktop environment developers do).
> 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.
Plugins can only be M-A:same if the application using it allows multiarch-
paths in some way so at least some will remain M-A: none. A lot of plugins
will be M-A:foreign (like possibly apt's transports) Some plugins can be
M-A:same or M-A:foreign for the same application (think of xul-extensions,
some are architecture dependent).
Some will work with different host-applications (think again about xul-
extensions) which might even come from different architectures
(iceweasel:amd64, iceowl:i386).
Some plugins might be even able to be used without their host (there is e.g.
no immediate reason for an apt transport to depend on libapt beside
developer lazyness. It features a text protocol so a human could use it as
a very simple wget replacement without big problems…)
Not all binaries will be M-A:foreign, some will be M-A:allowed and an awful
mass will be M-A:none as we (or just the maintainer) doesn't care for M-A
(I can't imagine a driving reason to make a game M-A:foreign for example).
And i guess the same mess can be created for bindings as the spec is way
to focused on python. I haven't really thought about it (or even used) but
e.g. lua could be binded to everything and still doesn't seem to need to be
M-A:allowed.
All i wanted to show with this is that it might be easy for a human being to
detect which type a package is by looking just at the name, but an computer
will fail to detect that without a lot of help. The help in this case would
be to require the usage of debtags for each and every package in the entire
debian universe and apply tags even to your homemade checkinstall packages.
Good luck with that given we are unable to land M-A in debian for years
(and even then consider it an example for good handling of big changes).
And last but not least: If you really thing about it, do we really want to
change the behavior based on the package we look at?
While a human has a good hit-rate, humans aren't unfailable either:
libc6, libsmbclient, libreoffice-zemberek, libreoffice-officebean
Which package is what?
Even then you know that libfoo is a library, this doesn't guarantees you
that it is also marked as such and/or already multiarchified. So you end up
being explicit always as you can't be sure what will happen otherwise in
different releases. Good luck if this involves not only different releases
but also different architectures… (not to mention distributions).
I would prefer to allow the user to concentrate on the problem (s)he has
and not so much on how apt will interpret the request. Understanding
dependencies is already complex enough and apt-get is a low-level tool,
so it shouldn't try to second-guess me - higher-level tools can try to be
nice and guess what the user wants (and are allowed to fail with that as
the user has still a backup tool what does exactly what it was told).
Best regards
David Kalnischkies
Reply to: