18

I was compiling a tool called Rejoystick so I installed a few packages and dependencies. But now I don't need it any more so I removed those packages. Running apt-get shows that I have some packages that are automatically installed and are no longer needed.

But I have a bad experience with apt-get autoremove. It broke my desktop environment when I uninstalled wine some time ago. Luckily, I had a clonezilla partition backup then, but this time, I don't have a backup. So I'm cautious. Running apt-get shows these packages are orphaned 

  gir1.2-gtk-2.0 libasound2-dev libavahi-client-dev libavahi-common-dev
  libcaca-dev libcairo-script-interpreter2 libdbus-1-dev libdrm-dev
  libexpat1-dev libfontconfig1-dev libfreetype6-dev libgl1-mesa-dev
  libglu1-mesa-dev libharfbuzz-dev libharfbuzz-gobject0 libice-dev
  libpcre3-dev libpcrecpp0 libpixman-1-dev libpng12-dev libpthread-stubs0-dev
  libslang2-dev libsm-dev libx11-dev libx11-doc libx11-xcb-dev libxau-dev
  libxcb-dri2-0-dev libxcb-dri3-dev libxcb-glx0-dev libxcb-present-dev
  libxcb-randr0-dev libxcb-render0-dev libxcb-shape0-dev libxcb-shm0-dev
  libxcb-sync-dev libxcb-xfixes0-dev libxcb1-dev libxcomposite-dev
  libxcursor-dev libxdamage-dev libxdmcp-dev libxext-dev libxfixes-dev
  libxft-dev libxi-dev libxinerama-dev libxrandr-dev libxrender-dev
  libxshmfence-dev libxxf86vm-dev mesa-common-dev x11proto-composite-dev
  x11proto-core-dev x11proto-damage-dev x11proto-dri2-dev x11proto-fixes-dev
  x11proto-gl-dev x11proto-input-dev x11proto-kb-dev x11proto-randr-dev
  x11proto-record-dev x11proto-render-dev x11proto-xext-dev
  x11proto-xf86vidmode-dev x11proto-xinerama-dev xorg-sgml-doctools xtrans-dev
  zlib1g-dev

I'm not sure if I should run apt-get autoremove. I was searching details related to each of these packages so that I can understand which ones are needed but they all seem important e.g.

gir1.2-gtk-2.0

I have Cinnamon, GNOME and Unity installed, I think apt-get autoremove will break something. Any help will be appreciated.

Thanks for reading.

usmanayubsh
  • 377
  • 5
  • 16
Shantanu Bedajna
  • 1,060

7 Answers7

15

As others mentioned, autoremove should be safe, but then again, you said that you have bad experiences, and I also remember autoremove removing some stuff that should not be removed.

It seems like autoremove can have problems with some meta-packages. Say you installed the gnome meta-package for the entire gnome-desktop (or it was installed when setting up the system), which also includes programs like evolution and lots of games, which you might want to remove, because you are using thunderbird and do not want to have those games and the like. This requires you to also remove the gnome meta-package, since it depends on all those packages. But this will make all the other packages that were installed as dependencies of gnome "auto-removeable", including e.g. gnome-shell, which you most likely want to keep if you want to continue using that desktop.

So it's always a good idea to check the packages recommended for auto-removal. If you are using a graphical package manager like synaptic, you can easily do so and uncheck the "automatically installed" flag from packages you want to keep (like gnome-shell in the above example). This will also remove all the packages those depend on from the auto-removeable list, so you might only have to "fix" a few of those, and not all.

Still, it should not remove anything that's really essential to your system, so even if you accidentally removed e.g. your desktop, you can still boot and log into your system and revert those changes using the command line.

Update: Recently, after a dist upgrade (Debian), autoremove actually removed something related to hard disc encryption (still not sure what exactly, probably related to the issue described here), causing my system to be unable to decrypt the hard disc and to boot with the latest Kernel. Luckily, it still worked with an older Kernel that was still installed and I could re-install all that was previously autoremoved, otherwise my system would have been wrecked, including my data.

I don't think there is a "undo last changes" option in apt and friends. In synaptic there is a menu option to see the last changes (File -> History; seems to just show some log files, although I could not find the logs themselves; also, I am not sure if this only lists changes made in Synaptic or also e.g. in apt etc.), so I copied the names of all the packages I autoremoved since the last successful reboot (luckily, I reboot daily) from those logs and re-installed them, then rebooted.

tobias_k
  • 351
  • "re-install all that was previously autoremoved" Could you please consider adding information about the actual steps one must take to recover from such a situation? – Levente Jan 29 '21 at 19:36
  • @Levente Added. I hope you did not have a similar situation. – tobias_k Jan 29 '21 at 23:09
  • No, I never had such a trouble, but I felt it's better to be prepared. By the way I could not find the last changes menu item in Synaptic... :\ – Levente Jan 30 '21 at 00:33
  • @Levente There should be an item "History" in the File menu. – tobias_k Jan 30 '21 at 09:37
  • @Levente copy /var/log/apt/history.log find the autoremove list and preface each package with sudo apt install then run as a shell script ... – Rob Kam Jul 13 '21 at 13:20
  • I am not sure if this only lists changes made in Synaptic or also e.g. in apt etc.), After opening this History menu item from within Synaptic, it was completely vacant, even though apt have just had recent changes i.e. installing synaptic itself. Thus, It's suffice to say that, this history is confined to software management operations conducted via synaptic, and synaptic alone. – xquilt Aug 22 '22 at 16:58
8

Surprising to see no one has yet mentioned the --dry-run and equivalent options:

From apt-get's man page:

-s, --simulate, --just-print, --dry-run, --recon, --no-act
No action. Perform a simulation of events that would occur but do not actually change the system.

Configuration Item: APT::Get::Simulate.
Simulate prints out a series of lines, each one representing an rpm operation: Configure (Conf), Remove (Remv), Unpack (Inst).

This option seems to work with both the apt and apt-get commands.

Example output:

sudo apt-get autoremove --dry-run
[...]
Reading package lists... Done
Building dependency tree       
Reading state information... Done
The following packages will be REMOVED:
  linux-headers-5.8.0-36-generic linux-hwe-5.8-headers-5.8.0-36 linux-image-5.8.0-36-generic
  linux-modules-5.8.0-36-generic linux-modules-extra-5.8.0-36-generic
0 upgraded, 0 newly installed, 5 to remove and 13 not upgraded.
Remv linux-headers-5.8.0-36-generic [5.8.0-36.40~20.04.1]
Remv linux-hwe-5.8-headers-5.8.0-36 [5.8.0-36.40~20.04.1]
Remv linux-modules-extra-5.8.0-36-generic [5.8.0-36.40~20.04.1]
Remv linux-image-5.8.0-36-generic [5.8.0-36.40~20.04.1]
Remv linux-modules-5.8.0-36-generic [5.8.0-36.40~20.04.1]

So I suggest one can run autoremove with the --dry-run option, study the output with a cool head, and decide what to do based on that.

An additional observation: if one runs autoremove regularly, then the autoremovable packages do not pile up, and thus it remains more doable to oversee and evaluate the output of each dry-run.

Levente
  • 3,961
  • 1
    What should one look out for in the dry-run output? Seems like it just states that it "removed" that packages it said it would remove, or not? Good point about if auto-remove, then in manageable chunks. – tobias_k Jan 29 '21 at 23:22
  • "What should one look out for in the dry-run output?" Anything that you manage to recognize and would disagree throwing away. If the list is much more extensive than you expected it, or if you manage to spot anything familiar in there, like software-updater, network-manager, python3, or something, then you don't run it for real, rather you investigate: why is it being removed? Has been a replacement already installed? If you can't figure out on your own, then you come to AU and ask how to sort it out... :) – Levente Jan 30 '21 at 00:18
  • 1
    But apt-get will show you "The following packages will be REMOVED:" and then ask for confirmation, anyway, or not? The output of dry-run just seems to repeat that list, possibly in a more readable form. – tobias_k Jan 30 '21 at 09:41
  • 1
    Yes, AFAIK that is right about the confirmation. But the dry-run additionally puts each package on its own Remv line during the "simulation" part. It may be easier to scan for some. Plus, I think there is a big difference in the attitude of the user. You are in a different mindset during running the command for real and then facing the confirmation prompt vs studying the output of a dry run. It's also about the human factor. The dry-run is an important line of defense against making a mistake. I thought it being an important enough factor to highlight. – Levente Jan 30 '21 at 11:12
  • 2
    I like this answer. I use autoremove every time I install a new kernel to get rid of the n-2 kernel. Sometimes also after installing a package that I end up not liking. But since my system is 'tidy', I can compare what it wants to remove with what it just installed. In my case, if autoremove wants to do something massive, it tells me I have made a mistake. – Organic Marble Feb 01 '21 at 13:26
4

Usually it should be save to run autoremove. But in case of packaging bugs essential packages might get removed. I made my system unbootable by running an apt autoremove, so I highly recommend quickly looking through the packages which are to be removed.

Edit: This answer describes how apt autoremove broke my system and how necessary steps to repair it.

lumbric
  • 3,994
  • 1
    What exactly should a person who would ask this question be looking for? – Eric Mar 06 '20 at 04:54
  • 2
    You are absolutely right, a beginner has basically no chance knowing which packages are supposed to be removed or could be dangerous. After using a debian based distribution for longer time you might know some packages or could guess from the time if it could be dangerous to remove it or not. For example removing a kernel could be a problem, but not if it is not the only one installed. The linked bug report removed support for decrypting the disk, so after a reboot I was completely stuck. Googling the package before autoremove would have saved me 5h. – lumbric Mar 06 '20 at 14:40
  • I just now saw your answer and that bug report That might have been what happened in my case, too (see "update" in my answer). – tobias_k Jan 29 '21 at 23:19
  • @tobias_k I've just added a link to the other Q&A which describes how to fix the system. Should have don that already in the first place I guess. – lumbric Feb 01 '21 at 09:50
4

apt-get remove can ABSOLUTELY destroy your system. It's happened to me twice and I can repeat it (on a Debian-based distro); both times on a vbox, so no big whoop. I watched it remove my entire XFCE installation.

SaveTheNeckbeards
  • 49
3

It should be perfectly safe to run sudo apt-get autoremove This should only remove packages that are not in use or needed any longer. If its a necessary package that would "break" your system if removed it shouldn't remove it.

mook765
  • 15,925
DnrDevil
  • 1,488
  • I would strongly recommend not using autoremove.

    In my case, two Ubuntu installs (16.04 and 18.04) got broken.

    It may also be related to my Desktop environment, which is Mate.

    I say this, because I had the same thing happen on a FreeBSD 11 install, that had Mate.

    It too recommended an autoremove, and following the suggestion, that install also got broken.

    Even if you don't have Mate, I still recommend against it.

     – mistige Nov 27 '19 at 15:26
  • 1
    I just used autoremove on 20.04 and spent two hours restoring my system using an external hard drive and another computer (on Windows, to make things harder). I have the standard Ubuntu environment. autoremove had removed gdm3, ubuntu-desktop, network-manager, among a big list of things. I learned many commands and places like mount, fdisk, dhclient, /etc/apt/sources.list, archive.ubuntu.com/ and such, which I will have completely forgotten in two days. And beware accidental strokes on the space key when using cp or rm, these can do much damage. – Arnaud Nov 28 '20 at 21:23
  • 1
    This assertion is in sharp contrast with the testimonials that numerous other people offer in this thread. – Levente Feb 01 '21 at 18:04
  • 1
    Also there can be a world of difference between what something should do, and what it actually does. Again, as testified by a lot others here. – Levente Jun 04 '21 at 21:41
  • It should be safe. And I should be rich. sudo apt autoremove just deleted hundreds of packages and hosed my wordpress installation. The mysql drivers are among what disappeared, along with who knows what else. – John Smith Dec 31 '23 at 01:03
2

From man apt-get: 

 autoremove
       autoremove is used to remove packages that were automatically
       installed to satisfy dependencies for other packages and are now no
       longer needed.

Have you installed other packages (and their dependencies), and subsequently removed the packages?

waltinator
  • 36,399
0

Firstly, you can try finding out what these packages are there for. Using apt show <package> is a good way. Doing this may lead to understanding like '*-dev' packages are mostly development files that have no impact on normal operation. In many cases they have been installed for compile work.

Secondly, looking into the list you may note there is one exception named gir-gtk-2.0. Apt tells it is for gnome-2.0 gui, which in your case could be useless.

In short, you'd better exlopre a little before making a decision. This question highly depends on the specific packages to deal with, rather than on some general principal as some suggest.

funicorn
  • 3,866