GkOrphan

Hello,

Orphaned packages are packages which are there aren't any packages that depends them. None of the packages require these packages. Sometimes these packages are required by programs that is installed by hand (It happened one time to me, I installed Firefox beta from source. And this installation required some libstdc++ package. This package was orphaned, when I removed it, my Firefox installation didn't work. This happens when you install many program by hand.). If you don't have this kind programs you can remove all orphaned packages I believe.

Hi Tahir

Thanks for your answer. I thought it's like this. Normally I don't install software by hand. But to be sure I won't remove these files *lol.
Peter

Hi Peter -

Imagine you used Synaptic to install a program some time ago, and now you decide you don't want it on your system. So you go into Synaptic, with the intention of removing it. You find the installed program, right-click on its name, and you are presented with the four choices

Mark for reinstallation
Mark for removal
Mark for complete removal
Properties

Suppose you choose "Mark for removal". ( After all, "Mark for complete removal" sounds a little scary, right? ) Then you click the "Apply" menu selection.

The likely result of doing it this way will be that you'll create an "orphan" file, a file that isn't used by any program at all, and serves no useful purpose on your system; it just clutters things up. You can avoid that problem by removing ALL of the program; including all of its "dependent" libraries; you do this by choosing "Mark for complete removal", instead. That's the best choice in all cases for systems that have used only Synaptic or apt to install software.

You're on your own, though, if you've installed programs "manually" ( by "manually" I don't mean "from a terminal command line, I mean "without using either Synaptic or apt", as by just downloading a tarball from somwhere, unpacking it, and running the resulting excutables directly, for example. ) I'm not sure of it; I don't have the experience to be absolutely certain about it, but I very much doubt you'd even be able to *see* such files in Synaptic, if you'd installed them "manually" in that way. I don't think there's any way Synaptic or apt could know of their presence on your system, in such a case.

Perhaps someone more experienced could confirm that?

The only problem with using "Mark for complete removal" that I can think of applies just to systems where software has been installed "manually" ( i.e. without using Synaptic or apt ). If you were to use Synaptic to remove "program 1" and all its dependencies, it's possible that some "program 2" you installed "manually" might actually need those dependent libraries. Synaptic would go ahead and allow you to remove the dependent libraries for "program 1", along with the main program itself, because it wouldn't be "aware" that "program 2" also needed those dependent libraries, in this example.

So if you've used Synaptic or apt to install all your programs, and have never "manually" installed programs just by unpacking a tarball and running the resulting excutables - which is very risky if you don't absolutely trust the site you downloaded the tarball from, by the way - you *can* remove "orphaned" files, and really should do so. More to the point, you should prevent "orphans" from arising in the first place by always using "Mark for complete removal" rather than just "Mark for removal" when you use Synaptic to remove any program.

So the best advice, I think, isn't "don't remove orphans", but "don't create them". Also, don't install programs without using Synaptic or apt. You want to make sure they get registered in the "installed programs and libraries database" that both Synaptic and apt use, and it's difficult for us non-hacker types to make that happen without using Synaptic or apt to install them. Or at least it is for me! ;)

This might be a little easier to make sense of this if you try two things:

(1) right-click on a currently installed package in Synaptic; let's try the "acl" package, for example. Look at it's installed dependencies, either by selecting the "dependencies" tab, in the lower panel, or by right-clicking on the "acl" package, > "Properties" > "Dependencies" tab in the resulting pop-up.
Either way you'll see three dependent libraries. If you were to mark the "acl" package for "complete removal" (don't do that!), and apply the change, Synaptic would be smart-enough not to remove any of those three dependent libraries if any *other* program in its database needed them. They'd be removed only if the "acl" package was the only program that used them.

(2) In Synaptic, click the "custom filters" button at the lower left corner of the screen. Then, from the main menu bar, select Settings > Filter. That allows two nice things to happen. The first is that when you click on one of the installed filters ( "Orphaned", "Broken", etc. ) you can see which boxes are checked to the right. The second nice thing is that you can hover your mouse pointer over each of the checkbox descriptions at the right, and see a short description of each, to get a little clearer idea of what each means. Of course, you can also create your own custom filters using this screen.

Finally, Hardy Heron 8.02LTS users should implement a workaround for an important Synaptic bug that's documented in launchpad at https://bugs.launchpad.net/ubuntu/+source/synaptic/+bug/8896 .
A fix was included in the Intrepid Ibex release, but as of today's date (15 April 2009) there's been no backport for Hardy released. See http://ubuntuforums.org/showpost.php?p=7065891&postcount=61 for a concise summary and simple instructions for implementing that and important workaround.

cheers,

- ami

Oh; I forgot to mention that using Synaptic's "Mark for complete removal" checkbox also deletes any configuration files that exist for the program you're removing. That's another reason to use it instead of just using "Mark for removal", in my opinion. The only reason I can think of where you wouldn't want to remove a program's user-configurarion files along with the program itself might be when you're testing, to try to overcome a system malfunction, and both of the following are true, (1) you plan to re-install it immediately, and (2) you want to retain your previous configuration settings.

Also, a clarification: the workaround I referred to at the end of the post immediately above will fix both Synaptic and apt on Hardy, and it's important to fix them both.

cheers, - ami

Thanks, Ami

It's nice, how you took the time, Ami. Thanks a lot.
Peter

You're very welcome, Peter. Thank you for saying so.

cheers, -ami

Have a nice time and be well. And thanks.
Peter