[Aptitude-devel] Bug#877716: Bug#877716: qalculate: Removing qalculate removes qalculate-gtk

[Manuel A. Fernandez Montecelo]

Hi,


(Thanks all for the input and for handling this).


2017-12-13 18:01 Axel Beckert:
>Hi David,
>
>David Kalnischkies wrote:
>> The autobit-moving happens for installed packages which change their
>> section to one of the mentioned sections on upgrade. Such upgrades will
>> remove the manual-installed marker from the now "oldlibs" package and
>> move it to the dependencies so that the oldlibs package will be cleaned
>> up automatically if nothing depends on it anymore – or if the user wants
>> to keep it for whatever reason just has to tell apt once about it.
>[…]
>> But the setup in this bug is a new installation of the "oldlibs"
>> package. There is no moving done here: Imagine installing libc5 to run
>> some really old thingy and apt continuously nagging you to remove it
>> because it happens to be in "oldlibs"… can't be done, hence the
>> complicated one-time move on section-changing upgrades.

(talking from the point of view of aptitude, not wanting to review what
apt does or how oldlibs came to be)

I understand that the behaviour described above was implemented to solve
some problems or user complaints, but for me, singling out sections and
having special rules doesn't make much sense, specially in the case of
aptitude.

If I see iceweasel as pulling firefox-esr and want to keep firefox, I
unmark it as auto installed explicitly if necessary.

IIRC there are similar discussions with metapackages from time to time
-- "if I install meta-kde it pulls a bunch of dependencies, but then if
I uninstall the metapackage, why is everything uninstalled?!?"

If implemented in the other way, another person would say: "OMG, you
force me to uninstall every single package that was installed by
meta-kde, because when I uninstall meta-kde everything is kept!  Why do
you force me to have to go through every single package?!!?  If I remove
meta-kde is because I want all stuff pulled by it removed, dammit!!"
(And this case doesn't account for what was once pulled in but it's not
a dependency anymore".

If I am not misremembering, I have seen similar discussions every now
and then on debian-devel@, so for me it's an open question, and I don't
like the package managers to try to be too clever in those cases -- at
least in aptitude, it tries to help e.g. with the auto-installed and
auto-removals, but it always puts the user in control.

So for me, that aptitude already informs about removing both packages
and asks for confirmation, is completely acceptable behaviour.


>> So, at least from an apt PoV (and like aptitude as well) this works as
>> intended although I see what you mean and agree that it is a bit sad
>> that you have to explicitly tell your package manager that you want to
>> keep qalculate-gtk after you figured out that you have needlessly
>> installed qalculate,

For me it's the other way around, I would wonder why it wants to keep
qalculate-gtk installed when the only rdep is being removed -- for me,
that qalculate is now in "oldlibs" is probably an irrelevant detail in
most actual cases when I want something removed...

>> but I don't see how we can improve this interaction
>> without breaking (or annoying) other usecases [In an ideal world you
>> would figure that out before installing qalculate as you are reading
>> descriptions and co before installation of course] – if there are good
>> ideas we could implement I would be happy to hear them!

... so yes, you would break my use-case, you evil person! :)


>Manuel: In case you think we should nevertheless add support for
>APT::Move-Autobit-Sections to aptitude (in case it's really not there
>yet, e.g. through libapt*), feel free to reopen this bug report or
>file a new one. (Or just implement it. ;-)

As explained above I don't see a compelling case to do it, the only
reason would be to match the behaviour of apt.

But then again, that's why we have different package managers, isn't it?

They don't need to be needlessly different, but I think that
historically aptitude is definitely a package manager with attitude :-)
, specially when it comes to put the user in control of what's
installed, so from my side I'd prefer if it continues with the current
behaviour.


Cheers.
-- 
Manuel A. Fernandez Montecelo <manuel.montezelo at gmail.com>