Bug#939813: tasksel: selected packages marked for removal on apt full-upgrade
Control: tags -1 + moreinfo
Hi,
Jeremy Turnbull <jeremy8258@gmail.com> wrote (9 Sep 2019):
> Package: tasksel
> Version: 3.53
> Severity: critical
> Justification: breaks unrelated software
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?
> 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.
The used concept of marking packages as manually or automatically installed
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
--
Holger Wansing <hwansing@mailbox.org>
PGP-Fingerprint: 496A C6E8 1442 4B34 8508 3529 59F1 87CA 156E B076
Reply to: