at bottom :- On 14/12/2017, Manuel A. Fernandez Montecelo <manuel.montez...@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.montez...@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