How does your package manager handle orphaned packages?

The last time I followed a distribution’s suggestion to remove some packages that were no longer needed, I completely hosed the system. Could not use it afterwards. Though the machine was a test machine, the experience thought me to always let sleeping dogs lie.

If what those orphaned packages, as they are called, are doing is just using up a few MB of disk space, then all is well. I do not recall whether the distribution was Debian, Ubuntu or a derivative, but I do remember clearly that the command the system suggested I use was apt-get autoremove.

The reason the system became unusable after running that command was that a major component still depended on an orphaned package. Is APT not smart enough to know this?

I have come across similar suggestions to remove orphaned packages after upgrading test installations of Sabayon, a Gentoo-based Linux distribution, but have largely ignored them. Yesterday, I decided to find out. The screen shot below shows the list of orphaned packages. This was on an installation of Sabayon 7 KDE, a distribution I recently reviewed. See Sabayon 7 KDE review. Notice that they were labeled as “orphaned vital packages.”
Sabayon 7 KDE Orphaned Packages

To remove the first orphaned package, I ran the following command: equo remove –pretends icedtea6-bin. A dry run. Afterwards, I ran the command without the –pretends switch. Repeated for the other two packages. For the third package, the dry run showed that an extra package was also going to be removed. Followed through.
Linux Orphaned Packages

What do you think happened to my test installation of Sabayon 7 KDE after removing the three (plus one) orphaned packages? Well, the most obvious hit the system took was that the network manager applet disappeared from the system tray. Not good! But considering that one of the “orphaned vital packages” was knetworkermanager, this was not really unexpected.

But why would the system label a package as “orphaned vital package?” Does that even make sense? How can a package be an orphan and be vital at the same time? Or within this context, does the term “orphan” have a meaning different from what I think it means? Whatever “orphan” means, the advise to self is this: Do not remove a package labeled as an orphan or a vital orphan on a production system.

So, my experience with removing orphaned packages on Sabayon and Debian or Ubuntu did not go too well. How does your distribution’s package manager handle such packages, and what was your experience in messing with them?

LinuxBSDos needs your donation to continue!

I hope this article has saved you valuable time and effort to fix a problem that would have taken more time than is necessary. That makes me happy, and why I love doing this. But because more people than ever are reading articles like this with an adblocker, ad revenues have fallen to a level that's not enough to cover my operating costs. That's why I want to ask you a favor: To make a one-time or recurring donation to support this site and keep it going. It's a small favor, but every one counts. And you can make your donation using Patreon or directly via Paypal. Thank you for whatever donation you're able to make.

Donate via Patreon. Donate via Paypal.

Aside from donation, you may also signup to receive an email once I publish new content. Your email will not be shared or traded to anyone. And you can unsubscribe at any time.

Please share:

We Recommend These Vendors and Free Offers

Launch an SSD VPS in Europe, USA, Asia & Australia on Vultr's KVM-based Cloud platform starting at $5:00/month (15 GB SSD, 768 MB of RAM).

Deploy an SSD Cloud server in 55 seconds on DigitalOcean. Built for developers and starting at $5:00/month (20 GB SSD, 512 MB of RAM).

Want to become an expert ethical hacker and penetration tester? Request your free video training course of Online Penetration Testing and Ethical Hacking

Whether you're new to Linux or are a Linux guru, you can learn a lot more about the Linux kernel by requesting your free ebook of Linux Kernel In A Nutshell.


  1. There were times a package or two were misconfigured in Sabayon and it’d want to install/remove 200 or so additional packages as a result. 🙂

    What you need is a package manager that uses a SAT solver. This guarantees that if a solution can be found to install a package, it will. In a test, 0.8% of the time it was possible for apt to install a package but it couldn’t figure out a way to do it. You can search for OPIUM online, which was the program created for a research paper that employed a SAT solver to install what apt could not.

    I’m using OpenSUSE and zypper, which does incorporate a SAT solver and lots of other powerful features. The APT folks might not have been interested in the work on OPIUM, but OpenSUSE was. 🙂 Unlike some of the other posters above, I don’t have to distrust, fear and personally inspect my package manager’s recommendations to remove things. I’ve been using openSUSE since July 2010 and have never had a problem when removing packages; so much so I choose to turn on zypper’s ability to spot and remove orphans each time I delete a package. Zypper is smart enough to recognize problems and offer the user a list of solutions: say, upgrade a package to enable an install, switch packages from one repository to another where the right versions may be found, etc. I’ve even seen it find a way to do what I’ve asked that involved downgrading from a 64-bit version of a program to 32-bit so it could change other libraries to 32-bit that an installation needed, although it did refer to this as “inferior”. 🙂 It’ll even let the user install broken packages if they so choose. It’s really quite nice and unlike my time with Sabayon, no hiccups.

    I’m glad I don’t have to keep notes about everything I install on my system like poor TobiSGTobiSGDD. 🙂 This is the reason Linux people have a reputation of being arrogant hackers. It doesn’t make one superior to have to take notes about every program installed on one’s system; it makes one antiquated and makes Linux look decrepit, poor and unusable for all but tech geniuses (and some Linux users want it that way). It’s embarrassing and when talking to Windows users about the benefits of Linux and the subject of distributions come up, I simply pretend Slackware doesn’t exist. 🙂 It’s the Windows 3.1 of Linux. As finid points out, the rest of us have better things to do and are glad to use technologies like package management to automate mindless tasks and focus on what’s important to us. Does Slackware even have a firewall or do users have to validate each incoming/outgoing connection by hand as well? 🙂

  2. Pingback: Links 13/12/2011: Ubuntu at HMV Stores, Ultimate Edition 3.0 Swaps Ubuntu | Techrights

  3. I am sorry but i have to agree emariz. APT is smart enough to tell you exactly what it will do. But you have to check all of them to see if you should remove them. All work on an algorithm but a package can be orphan but in the same time it is an usable one. It doesn’t have to depend on other program for a package to be orphan.

  4. Debian does have deborphan:

    Description: program that can find unused packages, e.g. libraries

    deborphan finds “orphaned” packages on your system. It determines which packages have no other packages depending on their installation
    and shows you a list of these packages. It is most useful when finding libraries, but it can be used on packages in all sections.

  5. I remove orphaned packages routinely, after every routine update, using (gentoo) portage’s emerge –depclean. However, I also follow it’s caution to examine the packages it lists and use my head as the human user/sysadmin of my own systems. If I see something I want to keep I simply add it to the appropriate set (as listed in my world_sets file, I’m running the still-masked portage series with full sets support and have everything in sets and an entirely empty world file) so it’s no longer orphaned, basically, as comment #2 suggested, adopting it. =:^)

    In general (as in, applying to all distros), “Orphan package” in context, simply means it’s not listed in the core required system set, nor is it in the list of packages or package-sets the user has deliberately chosen, nor is it listed in those package dependencies. In ordered for it to have gotten on the system in the first place, however, it would have had to be a dependency of something at some point and thus pulled in. That package (or packages) no longer list it as a dependency, and it’s not in the list of deliberately installed or core system packages, so it’s a candidate for removal.

    However, because it was a dependency at some point, there’s a small risk that whatever pulled it in still depends on it. That’s where sysadmin judgement comes in. It’s also possible that it was pulled in as a dependency of something originally and the user found they like it, but it was made optional. In the second case, adding it to the list of deliberately installed packages (however one does that on their particular distro) “adopts” the package. Alternatively, the stated dependencies could be fixed, and/or the packages still depending on the orphan one could be rebuilt to not depend on it.

    On gentoo at least, there’s a specific tool called revdep-rebuild that helps scan for and rebuild packages that have dependencies that aren’t installed (so post-removal), and it has a mode to request that packages be rebuilt if they depend on something that’s a candidate for removal, as well. Meanwhile, emerge –depclean is far more careful in what it removes these days as well, doing its own scan to see if any executables or libraries still depend on it first, and telling you what it might have removed because the package isn’t in the official dependencies, but won’t, because an executable still depends on it to run, too. The user/sysadmin can then manually rebuild the depending packages, hopefully removing the dependency, so depclean can finish the job. Alternatively, if the admin judges that it’s not a critical dependency, they can emerge –unmerge a package directly, bypassing the safety checks, and then let revdep-rebuild do its thing.


  6. APT is smart enough to tell you exactly what it will do. But you were dumb enough to say yes to all.

    • So APT is smart enough to label a package that is still being used by another as an orphan, right?

      • Yes, APT does it. This is more obvious if you use Aptitude instead of Apt-Get, because the former demands a logically stricter dependency chain, and all packages are indeed labelled as “manually-” or “automatically installed”. Those labelled as “manually installed” cannot be orphaned.

        Apt-Get, on the other hand, will only list orphans if you use the “auto-remove” option.

  7. No problems at all. Using Slackware I have to keep track of those packages myself. Humans are the best package managers out there.

    • Nah, humans are the absolute worst package managers by far, that’s why a coherent dependency-based system like RPM eventually led to the so-called RPM hell! Humans simply cannot remember and process much information efficiently! It is both time / energy consuming and plain stupid to resolve / keep track of packages yourself, sorry. Unless you do it for the “fun” of it (??) or you never update / upgrade your system.

      • TobiSGTobiSGDD

        So in your eyes all Slackware users are plain stupid?
        I don’t know of any dependency problems, have no meta-package problem and, yes, i upgrade regularly. So you can’t remember what you have installed and why? That is what text editors were invented for, just write it down.

        • It’s kinda tedious to keep track of all the packages one installs, and even more so keeping track of dependencies.

          That would make just managing applications on a system a full time job.

  8. if orphan… adopt it! 🙂

    • :)) That’s true.But unfortunately in this case you can’t really do that.I had problems with orphan packages but after I’ve erased them everything went smoothly.

Leave a Comment

Your email address will not be published. Required fields are marked *