Dear Maintainer,

The real packages that are installed from the metapackages that tasksel uses
will be marked for automatic removal after the next full system upgrade because
neither the metapackages nor the real packages are marked as being manually
installed to apt, and the metapackages are not listed as dependent packages of
tasksel, which is the only one of these packages that is marked as being
manually installed.

After upgrading from Debian 9.9 to 10.1, I had over 300 packages marked to be
automatically removed. Looking through the list, some of them were what I would
consider as "core" packages to my desktop computing environment, packages like
LibreOffice, Firefox, and XFCE. I used 'apt install' to both mark some of these
packages as being manually installed and to ensure that I was not missing any
new, dependent packages. The problem was, I missed that the network-manager
package was also marked as automatically installed and set to be removed, so
after my next 'apt autoremove' and system reboot, my system had no network
connection and was missing a lot of the packages necessary to create one.

Luckily, I still had a Debian 9.5 installation thumb drive lying around and
was able to boot that into rescue mode and inject the network-manager package
into my root filesystem. However, actions such as this or knowing to scrutinize
the list of packages marked for automatic removal are not behaviors that should
be expected of normal users. The list of packages that automatically will be
removed should not break the system or remove core functionality.

If possible, probably the easiest fix would be to ensure that packages tasksel
marks for installation are also marked as being manually installed to apt.

Hi,

Jeremy Turnbull <jeremy8258@gmail.com> wrote (9 Sep 2019):

First of all, I wonder why this did not came to notice for such a long time.
I thought RC bugs would trigger an automatic package removal from unstable,
if not marked fixed for a longer time?
follows a specific goal:
to give the possibility to keep the system up-to-date, but - at the same time -
get rid of no longer needed packages (say: remove cruft).

From your report I assume you installed a desktop environment task within
the tasksel step of the installer.
If you have selected the xfce desktop for example, that would lead to the
package 'task-xfce-desktop' being directly installed, which then pulls lots
of package in due to dependencies.
This 'task-xfce-desktop' package would then be marked as manually installed,
while all the dependencies would be marked as automatically installed.

This way, all would work well so far, as long as this 'task-xfce-desktop'
is installed and remains installed! Then, all the dependencies would remain
installed too, since they are needed by the 'task-xfce-desktop' and that is
not automatically removed, because it's set to 'manually installed'.

Long story short: maybe that task package was removed on your system for
whatever reason?
In that case, it would be "correct" to remove many dependency packages.
Or some other manual interaction has been done, to show such follow-ups?



I have verified this via an installation of Stretch with xfce desktop,
then upgraded to Buster, and all looks as described above:
the 'task-..." package is still set to 'manually installed', most of the
dependency packages are set to 'automatically installed' (comparing the
list of automatically-installed packages from before and after the upgrade,
there are only 7 packages removed from that set, and many more added to
this set; that looks fine to me).

When I now issue 'apt-get autoremove' it wants to remove 169 packages.
With ~1400 packages installed after the dist-upgrade, I would count a cleanup
of 169 packages not that unrealistic.
And performing this autoremoval did not show any grave defects during a quick
look.


So, at the end, I fear without further information or installation/upgrade logs
we are tempted to count this as unreproducible...


Best regards
Holger