Welcome, Guest. Please login or register.
Did you miss your activation email?

Author Topic: [EN] When Do You Know When It's Safe to Let Packages Be Removed or Autoremoved?  (Read 2604 times)

Offline tranquil

  • User
  • Posts: 111
I've had this question for quite some time, but it was raised again with the recent Perl transition. I held Perl for the first dist-upgrade today because of this:


Code: [Select]

The following packages were automatically installed and are no longer required:
  libcairo-perl libextutils-depends-perl libextutils-pkgconfig-perl libglib-perl
  libpango-perl libperl5.28 perl-modules-5.28 pkg-config
Use 'sudo apt autoremove' to remove them.
The following packages will be REMOVED:
  libgtk2-perl
The following NEW packages will be installed:
  libperl5.30 libsnmp35 perl-modules-5.30
The following packages will be upgraded:
  libalgorithm-diff-xs-perl libapt-pkg-perl libb-hooks-op-check-perl libcairo-perl
  libclass-c3-xs-perl libclass-xsaccessor-perl libclone-perl libcommon-sense-perl
  libcrypt-ssleay-perl libdatetime-perl libdevel-callchecker-perl
  libdevel-caller-perl libdevel-lexalias-perl libfcgi-perl libfile-fcntllock-perl
  libglib-perl libhtml-parser-perl libio-pty-perl libjson-xs-perl
  liblinux-epoll-perl liblist-moreutils-perl liblocale-gettext-perl
  libmath-random-isaac-xs-perl libnet-dbus-perl libnet-dns-sec-perl
  libnet-libidn-perl libnet-ssleay-perl libpackage-stash-xs-perl libpadwalker-perl
  libpango-perl libparams-classify-perl libparams-util-perl libperlio-gzip-perl
  libref-util-xs-perl libsereal-decoder-perl libsereal-encoder-perl libsnmp30
  libsub-identify-perl libsub-name-perl libtext-charwidth-perl libtext-iconv-perl
  libtype-tiny-xs-perl libunicode-utf8-perl libvariable-magic-perl
  libxml-libxml-perl libxml-parser-perl libyaml-libyaml-perl perl perl-base snmp
50 upgraded, 3 newly installed, 1 to remove and 0 not upgraded.
Need to get 16.7 MB of archives.
After this operation, 48.4 MB of additional disk space will be used.


However, I checked the transition site afterwards and saw that Perl was no longer listed. So, I went ahead and let libgtk2-perl be removed and autoremoved the others listed as no longer required.


When do you know when it's safe to let packages be removed or autoremoved without communicationg with the developer(s)? I'm sure the developer(s) do not want users contacting them about whether or not it's okay to let packages be removed or autoremoved.
Dual-booting Debian Stable and Unstable with Openbox window manager and Tint2 panel.

Online dibl

  • siduction community member
  • Global Moderator
  • User
  • *****
  • Posts: 2.345
    • Land of the Buckeye
If you are suspicious about a package that is to be removed, you can always check Debian Packages for guidance.  In this case, you will see that libgtk2-perl is no longer listed for the unstable branch, meaning it is safe to remove if you intend to keep an updated sid system.
System76 Oryx Pro, Intel Core i7-11800H, SSD 970 EVO Plus;  Asus ROG STRIX X299-E, Core i7-7740X, Nvidia GTX-1060, dual monitors, SSD 860 EVO

Offline tranquil

  • User
  • Posts: 111
Thank you dibl. I just checked the Debian Packages site and libgtk2-perl is still listed for the Unstable branch. However, there appears to be a qualifier: oldlibs. Is it the oldlibs qualifier that tells one that libgtk2-perl is no longer necessary for the Unstable branch?
Dual-booting Debian Stable and Unstable with Openbox window manager and Tint2 panel.