Phew, this one was tricky. I'm sure many of you, like myself, have gotten a bit carried away with the emerge --update command and as a result have found files lying around on the system that belong to older versions of packages on the system. emerge -s does not give you all the gory details, although qpkg -I will. It is necessary to unemerge the specific versions themselves in sequence, but it was a cumbersome procedure - until now!

This script inherits some of the ideas explored in my previous scripts. It determines all installed packages on the system, then determines which ones are stale. It will show which ones are stale and, optionally, delete them by iterating through each one, invoking emerge -C on each specific one. If you run the script without any parameters it gives you a small report and shows you which packages it would unmerge. Re-invoking with --nopretend as a parameter will make it actually unmerge the packages. I have tried hard to make sure it can parse the version formats of all the packages and it seems to work very well. Note: you can expect some of these ideas to go back into my staledistfiles script which I posted before, as the version checking in that script was not perfect!

As ever, suggestions and feedback in general are welcome. I hope you all find this useful!

Hmm, found one package that doesn't pick up - at least it's harmless . Let me know if there are any others it doesn't pick up. You can always validate it did find *all* the stale ones by browsing through the list: qpkg -I | less. There shouldn't be any two lines next to each other featuring the same package ...

Gave it a try and got the error::
Missing right curly or square bracket at ./emergeclean.txt line 101, at end of line
syntax error at ./emergeclean line 101, at EOF
Execution of ./emergeclean aborted due to compilation errors.
This isn't a perl script is it?

_________________Even if you're on the right track, you'll get run over if you just sit there.
-- Will Rogers

Yes, it is a Perl script. You might be getting that error because the forum page inserts line breaks where that shouldn't be any, because the browser window isn't wide enough. I don't know what window manager or text editor you are using but cutting and pasting should preserve the carriage returns properly in most cases. If this is a problem, I'll just have to crop the lines to be narrower. All lines finish with a semicolon ; apart from comment lines beginning with a # and block indicators { } and line breaks musn't be in the wrong places, otherwise you will definitely get errors. It runs fine.

Isn't this functionallity provided by the emerge clean option of the latest emerge?

For instance I've installed glib and gtk version 1.2 and 2.0, the lower will get unmerged while these are needed by some packages, whats wrong with using emerge -p clean?????, this takes the SLOT variable into account. Well it ain't perfect yet, but then I use qpkd --dups (gentoolkit) and clean up by hand, only a very few packages._________________"Remember there's a big difference between kneeling down and bending over.", Frank Zappa

Bah! I just wrote a detailed reply to your post, lx, and lost my net connection Anway, yes you're right, it doesn't take into account slots, however I had wanted it to be aggressive which is, of course, why it doesn't delete anything unless told to. See here for why I felt the need to write it, as you say, it ain't perfect yet or at least it wasn't: https://forums.gentoo.org/viewtopic.php?t=3240

Anway, yes you're right, it doesn't take into account slots, however I had wanted it to be aggressive which is, of course, why it doesn't delete anything unless told to. See here for why I felt the need to write it, as you say, it ain't perfect yet or at least it wasn't: https://forums.gentoo.org/viewtopic.php?t=3240

Well I didn't say it wasn't perfect I just wanted to point out some dangers, I'm the lazy one sitting on my rear ass, what I should build is a remove function which takes the bootstrap / system / world (packages installed by hand) files into account and when deleting calculates all unused dependencies and prints them for your approval, and when you agree deletes them. Think it would be a very very very cool feature, this way you can emerge something for testing and you don't have to remember all the other packages which get installed. This will also clear out stale packages, because newer package will satisfy the dependency and get removed from the remove-list instead of the older versions. But well as I said I sit on my rear ass (I'm becoming quit good at it) and just tell you what I should supposed to be doing, you on the other hand are just doing it (probably also sitting on your ass)...... damn I'm tired,

Cya lX.

Maybe I will put this idea in the suggestion forum, but for now I'm too tired to search for another post stating the same idea._________________"Remember there's a big difference between kneeling down and bending over.", Frank Zappa

It does list "stale" packages for sure, but it also suggests to update "dependency-packages": I mean upgrade to a higher version of packages that have "only" been installed because of dependencies.

I guess this is similar to emerge -p --deep world.
Won't this break things?

Example: I emerge progX, and I need to emerge A and B as dependencies for ProgX to work. If I now update A and B, there is a chance that ProgX will be broken because of these updated dependencies, right?

Well I don't know if it brakes anything but it may very well do this, but I want to have the latest packages installed, and that's what this script shows, (emerge -p -e world (clean install)). Some update can cause other packages to break and these need to be recompiled. A script that takes installed packages into account would be better for most people, but it would be a lot more complicated.

More general it's a problem if you upgrade a package it can brake other packages because the new package has a different library name c.q. different functions. changing your use flags can be a big problem also.

The portage system should take into account when updating / unmerging packages which libraries are removed and if programs depend on them (and if the updated packages replaces them), but then you still have a change of breaking you system because of incompatible version.

Although I can run ldd on al my binaries and libraries quite fast doesn't mean that everybody can. I have one time needed this script, to check which packages needed to be rebuild after updating some packages (using "not found" as argument):