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

Manuel A. Fernandez Montecelo manuel.montezelo at gmail.com
Mon Dec 18 00:38:07 UTC 2017


2017-12-14 23:13 GMT+01:00 David Kalnischkies <david at kalnischkies.de>:
> On Thu, Dec 14, 2017 at 12:58:10AM +0100, Manuel A. Fernandez Montecelo wrote:
>
>> So for me, that aptitude already informs about removing both packages
>> and asks for confirmation, is completely acceptable behaviour.
>
> Yes and that is completely fine. aptitude with its interactivity gives
> very fine control over such things, something apt (or e.g. a gui
> software center on top of apt) doesn't. It/they kinda have to guess what
> the user meant as we can't really ask – nor can really expect a "normal"
> user (whoever that is) to have a good opinion on it.
>
> So apt takes the stanza of: The user will know exactly which packages
> (s)he wants to have installed/removed (= named explicitly on the
> commandline), but all the details like version, dependencies and stuff
> are left for apt to pick sensible things for (+ extreme backward-
> compatibility – lets remember that the autobit itself is a backport from
> aptitude and hence subject to compat-worries – and debian policy and you
> have it).
>
> aptitude expects more choices to be made by the user – and if only by
> accepting the default actions it picked – with the assumption that the
> user will know what is sensible [for him/her] and pick that instead if
> (s)he wants.

Yep, the interactivity for confirmations is what it makes quite a
difference in situations like this :)


>> > > 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...
>
> We were imagining a user installing qalculate here (which installs
> qalculate-gtk) later reading the description telling the user that
> (s)he can just easily and safely remove the package… but that marks
> qalculate-gtk for removal, something the user didn't want to happen as
> (s)he was just following "orders" (or in apts upgrade scenario not
> remove the package making the user not-unhappy¹ as it works as (s)he was
> told)

I was imagining something like a user installing qalculate back in
2014, then at some point it depends on qalculate-gtk so it installs
that silently; and the user in 2017 noticing some "qualculate" in an
upgrade and thinking "I don't need that anymore, purge now!! MOAR
SPACE!!!1!!!", and expect all unused dependencies to go away.


In the case that you mention I also expect aptitude to delete both
packages for me (being only a small annoyance on that particular
situation if things were otherwise).

Even if I do install and uninstall it immediately and not 3 years
later, the reason why I expect everything to be removed is that maybe
I try it and decide that it's an awful application anyway, so
uninstall right away.  I don't want second guesses about
which-depends-on-what and maybe you really meant this other thing.  No
second guesses about oldlibs, metapackages or nothing -- I don't care.
If auto-installed and all rev-deps removed, drop it.   No rdeps and
autobit -> go away.  (And modifying auto-bit behind my back not good).

On the other hand, I tolerate (if not expect) aptitude to be dumb
enough so I have to hold its hand and mark the -gtk explicitly if I
want "oh, drop this empty shell, but I do really want that package
that it points to".

In other words, ot's OK for me to do extra work myself when aptitude
takes the most obvious/straightforward answer in an ambiguous
situation (obvious for me, anyway), like marking -gtk to be kept
manually when it was going to be auto-removed, but it's not OK taking
a contrived decision and then I having to do work to undo the
too-clever solution that it wants to take.


> ¹ as we all know: users are never happy. They are just sometimes briefly
> in the state of not wanting to report a bug, which makes some of them
> unhappy…

Well put!  Indeed they are, that's the nature of those pesky users!


>> But then again, that's why we have different package managers, isn't it?
>
> We have different package managers because you haven't been enlighted
> yet. One day you will see supercow as the superior easteregg overlord it
> is over this petty elephant-eating snake, but until then you are
> destined to pass your time playing minesweeper^W^Wmaintaining this
> heretical wannabe package manager… may the cow have mercy with your
> soul. (SCNR)

I can only hope that one day I may be worthy of the Despise of Her Milky Lady :D


> On a more serious note, I think I already outlined that further above,
> but in short: Different user expectations both from the side of the user
> and of the program. Thankfully a user can switch between all of them
> rather easily – much simpler than changing text editors^W^Wdesktop
> environments…

So also more serious (not cranky I hope, don't read it that way, just
trying to explain my view about what aptitude is and what fits)...

Yes, I think that it's reasonable that apt takes more decisions for
the user as you explain, it makes complete sense, so I am not arguing
that one is better than the other, it depends on the moment and what
it's designed for.


Stepping back and getting more philosophical... I think that we have
different package managers so they can raise above simple tars and
track dependencies, then raise above simple dependencies and perform
the necessary network-related incantations so you can launch your
package without hassle, and then even keep track of the state of the
whole system so you can micro-manage it and control it like a freak
looking closely every single package of your system, provide ways to
track packages automatically to force them out the door as soon as
nothing is poiting at them, inspect packages' changelogs before
installing/upgrading, navigate back and forth looking for fussy
packages that make that awful ruby2.3 installed in your system and try
to do without it, or going really out of its way and compute for many
minutes or even hours a solution for this incredibly complex GCC-5
C++11 transition.

I think that aptitude is (or was) a step above, or beyond, the other
package managers; maybe a step too far and that's why most people
prefer apt; but I always saw it as a step beyond in most aspects.

Apart from any ideas about aptitude that the original author might
have had in mind (taking over the world or at least over apt maybe,
but maybe not, not sure), I think that aptitude is really well suited
and it's at the pinnacle of package management when one wants to take
care of one's own system and control every single aspect of it, and
specially suited for people using rolling releases like Debian
unstable and picking upgrades carefully.

Many people don't like to manage through curses, because it's more
sluggish or for any other reason; and it's not really well suited to
manage many machines and probably not very advantageous if one uses
stable or upgrades everyday unstable without thinking.  (I often use
apt myself for many of the more mundane tasks of installing
dependencies to compile something in a system that I don't care about,
or update+upgrade to the latest updates everyday).  But as kind of
"bridge of the Enterprise", to control every single package-related
detail about your ship, I think that it's unmatched (not only in
Debian -- I didn't survey, but even yum or dnf or other solutions that
I have experience are far far behind, in my experience).

So I think that attempts at second-guessing or taking actions instead
of suggesting the most straightforward actions and always putting the
user in control, is not very suited for aptitude design/goals/target
audience, and I think that this issue crosses that line.


(Sorry for the length if you reached here :) ).

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



More information about the Aptitude-devel mailing list