[Aptitude-devel] Bug#729526: Bug#729526: ssh.deb: somewhat misleading description

[Manuel A. Fernandez Montecelo]

Hi,

First of all, and FWIW and on a personal note, I am happy with the
current behaviour of aptitude, at least it's predictable :) , and forces
me to think about the need of that package in my system.

Judging by the bug reports that aptitude receives, one of the major
complaints is when packages loose the auto-installed flag for whatever
reason, even if leaving a package installed is harmless in most cases --
so I am not sure if changing this in the ways suggested would make
(many) users more happy.

Even with the current behaviour, in most cases the package will remain
installed if it's recommended by other packages installed and so on, so
the behaviour described in this bug report will not be triggered in
many/most occasions even when the transitional package is removed
(although maybe it's not very common to have dependencies on servers, as
it's this case).


Apart from all that, I am a bit confused about this whole bug report,
because it's mentioned several times that the package is in "oldlibs" or
that this is a "transitional" package and what happens when they are
removed or "obsoleted", but "ssh" is neither.  It's just, as the
description says, a convenient (???) way to depend on both
openssh-{client,server}, but it's not "transitioning to be removed" in
any way, as far as I can see.

Since it's not in "oldlibs" section, or "metapackages" or "obsolete" or
anything of that sort, all the mechanisms that have been mentioned in
previous messages of this bug report, such as Never-Markauto-Section, do
not apply here.  (And no, aptitude doesn't implement anything related
with that variable at the moment).


So this question instead is similar as to what happens when you have a
"kde-desktop" or "kde-artwork" package depending on a bunch of default
tools and data files -- should all those packages be marked as manually
installed?  Isn't then a hassle to go through 50 packages and explicitly
remove them when you decide that you don't want KDE in your system after
all?

I think that there have been discussions about this in debian-devel not
long ago, and I got the impression that there was no consensus on the
matter.

If we want the behaviour to be "installing kde-desktop is an alias to
have all these packages installed" as a permanent action, so then we are
able to remove that one while the others remain installed, perhaps it
would be better to consider some different implementation, instead of
"virtual metapackage" it would be something like "package actions".
Otherwise, the idea of auto-installed package is completely unintuitive
for these cases.  "tasks" seem to fit well in this category, even the
name is closer to "action" than to "meta-package".  ...But then again,
it's probably too big a change for a very small gain.


So, in summary, I don't think that the solution proposed is better than
the current behaviour [of aptitude].  I am not opposed to implement
this, but in that case I would like to see some incipient consensus on
the matter (or, if apt implements it in that way, I'm not that keen in
overriding it).

But for that to work properly, the "ssh" package would have to signal in
some way that it's indeed a meta-package or intended to be obsoleted,
for example being in section "oldlibs" (or even "metapackages"?) instead
of simply "net", so at least package managers like apt and aptitude can
infer something useful about it, rather than just try to guess whether
the dependency on openssh-{client,server} is because it's a metapackage
under cover.


Lastly:

2017-04-02 11:55 David Kalnischkies:
>
>[...]. In case that isn't reimplemented in
>aptitude already, it might be a better idea to talk about this again at
>the start of buster as I want to move this out of the solver for a while
>now as we need that for the external solvers as well.  It is just
>a matter of "how" API wise which probably will result in a bunch of code
>changes as well… so it is always "later".
>
>As a first step it might be interesting to figure out how the API would
>need to look for aptitude to be able to use it (or in which calls we can
>hide it to have no API for it at all as that is what we need to do for
>compat reasons for all other frontends).

Perhaps as a simple boolean argument of a function, so a Remove() of
"obsolete" / "oldlibs" package would consider keeping the dependencies
based on APT::Never-MarkAuto-Sections and that flag (that is, setting
the auto-installed bit on the dependencies to "manual", or not).

Or perhaps no API exposure at all, just respecting that config option,
and interested aptitude users would have to override the behaviour.


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