'upgrade' in bionic should by default autoremove as well

[Mark Shuttleworth]

In bionic, apt upgrade should also autoremove by default. I have a few bionic systems (upgrades from xenial mostly) which are not yet showing that behaviour, it may be we haven't implemented that yet so this is just a placeholder bug in that case :)

[Julian Andres Klode (juliank)]

automatic autoremoval is a difficult topic with a lot of things to consider:

* autoremoval is not safe to do. Users often end up removing a lot of stuff they don't want to remove. So this needs careful checking. (dist-)Upgrades already have long output and people miss removals already, adding automatic removals makes them even more likely to miss things.

* The packages being autoremoved are not necessarily related to the package changes being performed at the moment. You could have removed a package at some point and your next upgrade let's say a week later removes all dependencies of the package - that's just seems like bad user experience to me.

* apt upgrade is defined to not remove packages - that is, it is safe to run with the guarantee of not losing any functionality. autoremove there would break that promise and thus expectations. For {full,dist-upgrade}.

So, I don't think we should just switch on autoremovals by default.

We should first focus on the aspects where it really matters:

* If you install an app via gnome-software and remove it, its dependencies should be gone too (but not other unused packages, as said before, that would be bad UX).

* When doing release upgrades, remove all unused packages. There's a huge amount of churn and people expect stuff to be broken / missing after a release upgrade anyway, so there's much less frustation.

(both have their own LP bugs, but I don't know which ATM)

Also we could do that gnome-software idea of a limited autoremove and push that to apt too and do that on remove/install/dist-upgrade. "upgrade" really is kind of a special case, though.

[Mark Shuttleworth (sabdfl)]

The main reason to do this is kernel cruft. We have had kernels being
flagged for removal for years now, and it's completely reliable. We
really should garden that automatically.

Mark

[Julian Andres Klode (juliank)]

Oh right, that's another use case I forgot about. I can see cleaning them up automatically in unattended-upgrades and dist-upgrade (or well, when any new kernel is installed). I just don't want to accidentally autoremove a desktop or something :)

I guess in essence we can just define a second level of autoremove that only removes safe packages, and just enable that by default. This way we can mark kernels as safe to autoremove, and still have an autoremove command that removes potentially less-safe unused packages. We can even extend that to other packages as needed.

Together with fixes for gnome-software and complete autoremove in do-release-upgrade (and perhaps the limited autoremove when removing a package) we should should have a solution that should not cause any big issues I think.

[Balint Reczey (rbalint)]

@sabdfl I absolutely agree that unused kernels should be removed, and it is being fixed in LP: #1624644 right now.

I strongly disagree on performing autoremovals of user space programs because Ubuntu's strength is not only in providing an experience which is consistently great across the system, but a great experience which is also consistent in time.

People would be upset finding their favourite work tool or solitaire implementation gone after the upgrade because GNOME decided to recommend a different one none at all.

IMO to provide the best experience apt commands should be left doing what they are doing well for years and LP: #1624644 should be fixed.

[Mark Shuttleworth (sabdfl)]

Perhaps we are talking at cross purposes. My expectation is that update
would list the packages to be removed because they are no longer
dependencies of packages that were consciously installed. On that basis,
there should be no surprise to users. The messaging could point users to
a handy document to understand how they can make a package stick around
by flagging it as one they have manually / consciously installed.

My point is that most users don't install
'linux-image-extra-4.13.0-15-generic' themselves, they have a system
with 'linux-image-generic' installed, and it's dependencies change over
time.

AIUI, we already have a good way of holding back from autoremoval
versions of the kernel which are currently in use, or which are the
last-best-guess-good kernel, or which are the next-kernel-to-boot. All
other kernels that were not explicitly installed by the user are simply
ephemeral to that user, and for the vast majority of users, those
ephemeral kernels build up over time taking large amounts of space and
slowing down upgrades thanks to the initramfs generation mechanisms.
Those kernels should go when they are deemed surplus; the user did not
ask for them explicitly, and the user isn't going to boot them either.

Here's what I have in mind, note the changes to text in the output of
apt upgrade. The user is prompted, and told how to avoid autoremoval.

$ sudo apt upgrade
Reading package lists... Done
Building dependency tree
Reading state information... Done
Calculating upgrade... Done

These packages were automatically installed and are no longer needed:
  libgweather-3-6, linux-image-extra-4.13.0-15-generic
Cancel this operation and use 'sudo apt install <package>' to keep them
from automatic removal.

The following packages have been kept back:
  libreoffice-help-en-us

The following packages will be upgraded:
  libio-socket-ssl-perl

1 upgraded, 0 newly installed, 2 to remove and 1 not upgraded.