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.”
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.
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?
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? 🙂
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.
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.
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.
Duncan
I have used OpenBSD package system for many years. The packaging system has developed a lot (by Marc Espie) during the last years. Upgrading has become easier and handling of orphan packages has been improved.
OpenBSD added a lot of ground work to package handling in OpenBSD 4.7.
“The New pkg_add For 4.7 (espie@)”
http://www.undeadly.org/cgi?action=article&sid=20100323141307
Package system was futher improved in later releases. See
“The long road to pkg_add -u”
http://www.openbsd.org/papers/eurobsdcon_2010_pkg_add/index.html
In my experience the package system has worked flawlessly (as most things do) in OpenBSD.
A simple “pkg_delete -a” will remove all orphaned packages. You can also force remove packages (using “-D dependencies” flag) and at the same time remove packages that will become orphaned due to the force remove.
OpenBSD package/ports system seems to be one of the most roubust and capable packaging systems out there.
“man pages for pkg_add and pkg_delete”
http://www.openbsd.org/cgi-bin/man.cgi?query=pkg_add
http://www.openbsd.org/cgi-bin/man.cgi?query=pkg_delete
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.
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.
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.
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.