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

[shirish शिरीष]

at bottom :-

On 14/12/2017, Manuel A. Fernandez Montecelo <manuel.montezelo at gmail.com> wrote:
> 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>
>

Dear all,

Thank you all for your efforts. Have not been in the best of health
hence took time to reply. Just read the whole backlog.

I was honestly under the impression that transitional packages had no
business other than when packages need to be transitioned, especially
if packages needed to some kind of voodo, lock-step kind of upgrade
(have seen/done it few times and is somewhat scary when those messages
are seen but that's outside the purview of the issue above)

>From Manuel's sharing I saw that apt indeed does take out qalculate
leaving out qalculate-gtk to do its work .

# apt purge qalculate -y
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following packages will be REMOVED:
  qalculate*
0 upgraded, 0 newly installed, 1 to remove and 5 not upgraded.
After this operation, 34.8 kB disk space will be freed.
(removed bits about packages and directories stuff for privacy)

Removing qalculate (0.9.9-1) ...

Also does nothing to qalculate's state -

$ aptitude search qalculate-gtk
                                                            [94%]
i   qalculate-gtk
- Powerful and easy to use desktop calculator - GTK+ version

I did see that qalculate has nothing in it except the changelog
(probably to do with transitions)

-- 
          Regards,
          Shirish Agarwal  शिरीष अग्रवाल
  My quotes in this email licensed under CC 3.0
http://creativecommons.org/licenses/by-nc/3.0/
http://flossexperiences.wordpress.com
EB80 462B 08E1 A0DE A73A  2C2F 9F3D C7A4 E1C4 D2D8