From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from lists.gentoo.org ([140.105.134.102] helo=robin.gentoo.org) by nuthatch.gentoo.org with esmtp (Exim 4.62) (envelope-from ) id 1HB903-00089W-CY for garchives@archives.gentoo.org; Sun, 28 Jan 2007 12:19:12 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.13.8/8.13.8) with SMTP id l0SCGwdr023300; Sun, 28 Jan 2007 12:16:58 GMT Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by robin.gentoo.org (8.13.8/8.13.8) with ESMTP id l0SCGw8w023291 for ; Sun, 28 Jan 2007 12:16:58 GMT Received: from list by ciao.gmane.org with local (Exim 4.43) id 1HB8xn-0007qG-AZ for gentoo-amd64@lists.gentoo.org; Sun, 28 Jan 2007 13:16:51 +0100 Received: from ip68-231-13-122.ph.ph.cox.net ([68.231.13.122]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 28 Jan 2007 13:16:51 +0100 Received: from 1i5t5.duncan by ip68-231-13-122.ph.ph.cox.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 28 Jan 2007 13:16:51 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: gentoo-amd64@lists.gentoo.org From: Duncan <1i5t5.duncan@cox.net> Subject: [gentoo-amd64] Re: unmerging slotted group packages Date: Sun, 28 Jan 2007 12:16:37 +0000 (UTC) Message-ID: References: Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-amd64@gentoo.org Reply-to: gentoo-amd64@lists.gentoo.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: ip68-231-13-122.ph.ph.cox.net User-Agent: pan 0.121 (Dortmunder) Sender: news X-Archives-Salt: 3f9adaf0-4766-4c64-82f0-7aca13da150b X-Archives-Hash: 2d7235da1bbb4e2747e97e7bd23aa074 "Daiajo Tibdixious" posted a4a9bfcb0701272117g58fdd9beof34ecba152619063@mail.gmail.com, excerpted below, on Sun, 28 Jan 2007 16:17:37 +1100: > I discovered by accident that I have KDE 3.3, 3.4, & 3.5 all installed > at the same time. > I wanted to clean out 3.3 (at least) and tried emerge -aC > =kde-base/kde-3.3.0 which of course just did this pseudo package, not > the containing packages. > I also tried emerge --clean kde-base/kde but this says nothing to > remove, even though 3.4 & 3.5 are still present: > [D] kde-base/kde > Available versions: (3.5) 3.5.2 3.5.5 > Installed: 3.4.3(3.4)(17:19:35 01/18/06)(-accessibility) > 3.5.5(3.5)(02:50:53 12/10/06)(-accessibility) > Homepage: http://www.kde.org/ > Description: KDE - merge this to pull in all > non-developer kde-base/* packages > > I got rid of 3.3 by doing eix -I kde & removing each sub-package > manually, I just think I must be missing an easier way. Two easier ways to do it, but with both, use --pretend first and ensure it's not going to remove something you know you need. Both of these depend on your world file being accurate, so proceed with caution if you know it's not. Each separate section is bullet-pointed with **, below, hopefully making it easy to follow. ** First, some general maintenance. You may have a bit of cleaning up to do here if you've not done it in awhile. There's a step that's normally recommended before the following, only at this point it'd likely cause a bunch of extra work due to stuff you will be removing anyway, so I'd say skip it this time. However, I'll note it at the bottom under pre-maintenance, and I'd suggest reading thru this entire message so you understand how it all works, before you start. OK, do an emerge --pretend --depclean, and see what's listed. It should list everything that's not either in your world file or a dependency of something in your world file. That's what portage thinks you don't need. If you think you need something on that list, do an emerge --noreplace so portage will add an appropriate entry to your world file for it. (If it's a dependency, aka a branch package that something else depends on, as usual, add the "leaf" packages that depend on it, thus keeping only "leaves" in your world file, so when all of them are removed, portage knows it can remove the dependency as well.) Once you have all the packages in your world file you know you need, so --depclean --pretend is only listing stuff that should be safe to remove (it won't be listing the KDE slots stuff at this time, most likely), go ahead and do the emerge --depclean without the pretend. That should leave you with all the "extra" packages removed. Generally, these will be old dependencies for "leaf" packages, old/dead branches with no current leaves. Up to this point you should do relatively frequently, just keeping the old cruft on your system to a minimum, as part of regular maintenance. There is another part to this that you should normally do whenever you are doing it for system maintenance. However, we'll skip that here since it could mean a bunch of extra work for stuff you are going to remove anyway. Thus, I'll list it at the bottom, under completing the system maintenance, after the old-KDE removal stuff. ** OK, now here's method 1, specifically unmerging the old kde slots: Specifically emerge --unmerge =kde-. This will unmerge the meta-package that's the leaf for all the other KDE packages (branches supporting that leaf) of that version. ** And here's method 2, using --prune: Emerge --prune will try to unmerge all but the most recently merged version of the packages in question. That's likely what you want for things like KDE, but it's definitely NOT what you want for things like autoconf and automake, for instance, since many packages depend on older versions and won't work with newer ones. Thus, ALWAYS use --pretend the first time you use --prune, just to be SURE it's going to remove what you expect it to, and nothing else, and NEVER do an emerge --prune world or system (except if you are curious, you can try it with --pretend, just to see what it would do if you were stupid and tried --prune world without the pretend). So... emerge --pretend --prune kde-base/kde, and see what it lists. If it looks sensible and it should, run it again without the pretend. ** Finishing up the unmerge: OK, either way you did it, you should now be clear of the old kde meta-packages, but you'll still have the actual packages merged. However, once the metapackage is unmerged, you can again run emerge --depclean --pretend, and portage should list all the dependencies of the slot leaf you just removed as stuff it'd now remove. If it looks correct, go ahead and do it again, this time without the --pretend. Again, if there's something listed that you know shouldn't be, do an emerge --noreplace for it so portage adds it to the world file, then when everything looks good, go ahead and remove the --pretend. ** Completing the system maintenance, revdep-rebuild: OK, now you should have all the old cruft removed, but we aren't quite finished yet. There's a possibility that some of the remaining packages are now broken, because they had seen and compiled against some of that old cruft, even tho they /should/ have compiled against newer stuff. Broken dependencies can also happen when you changed USE flags and didn't recompile everything that used those flags with the new flags. --depclean doesn't understand these cases, and so sometimes removes stuff that's still needed, but there's a tool designed to fix it: revdep-rebuild, which is part of gentoolkit. So, if you don't have gentoolkit merged, emerge it. Then, run revdep-rebuild --pretend (remember, unlike --depclean, revdep-rebuild is it's own command, not part of emerge). Depending on the speed of your disk and amount of memory, revdep-rebuild will take a half an hour or so to scan all the executables and libraries on your system and ensure they have all their library dependencies met. If they don't, it'll figure out what you have to remerge to get things working again, and either do it, or with pretend, give you a list. If you've not been keeping up with system maintenance, especially if you just --depcleaned a bunch of stuff as we just did, and/or if you don't regularly do emerge --newuse world after changing your USE flags, you'll likely have a bit of a list of stuff that needs rebuilt, thus the --pretend the first time, so you get a bit of warning at how long it might take. Once you know what revdep-rebuild thinks you need to remerge, you can run it again without the --pretend, and it'll do it. (It won't take all that time figuring stuff out again, as if there's actually anything it needs to remerge, it saves the work files from the --pretend, so it can get right to work the second time.) Once you have everything rebuilt, if you like or I'd recommend it if you had a lot to rebuild, you can run revdep-rebuild --pretend once more, just to be sure. Once it says you are clean, you'll have a nicely sparkling clean system, freshly de-crufted and with all dependencies verified by revdep-rebuild. =8^) ** Pre-maintenance, emerge --newuse and revdep-rebuild: As I explained near the top, emerge --depclean is an important part of what should be routine system maintenance, just to keep your system free of cruft. However, when done routinely, there's a couple things you can do before the --depclean to keep things from breaking with the removal of that cruft and therefore needing rebuilt with revdep-rebuild. I suggested skipping them this time only because with all that old stuff on your system, you'd have likely been doing a lot of extra merging for stuff that you were just getting ready to clean out. However, if you do it routinely, say every three or six months, after any big removals such as old KDE slots, and after changing your use flags, there won't be that much stuff out of date anyway, so doing this pre-maintenance is a good idea as it'll keep stuff from breaking with the --depclean. For routine maintenance, then, your first steps should be the following: emerge --newuse world (first with --pretend, or with --ask, of course). This makes sure all packages are remerged that have had their USE flags changed. Since USE flags often determine dependencies, changing USE flags often means changing dependencies, and remerging any packages with changed flags then updates the dependencies so they don't break when --depclean removes stuff based on current USE flags. revdep-rebuild (again, first with --pretend, or with --ask). Do this before your emerge --depclean, after emerge --newuse, and in theory, nothing should be broken after your emerge --depclean. ** Summary of routine system maintenance, step by step: Here, in short form and for further reference, are the steps that should be done routinely, say every 3-6 months, and after USE flag changes or after major upgrades (stuff like KDE, GNOME, XORG, GCC, etc). 1) emerge --newuse world 2) revdep-rebuild 3) emerge --pretend --depclean 4) emerge --noreplace as necessary 5) emerge --depclean 6) unmerge old slots or major packages if desired 7) repeat steps 3-6 as necessary 8) revdep-rebuild 9) verify with another revdep-rebuild if desired Nice clean system! =8^) If done in this order, there shouldn't be much if anything to revdep-rebuild the second time, in step 8. ** Notes: - Again, while skipping step 1 and 2 if you haven't been keeping up with the routine maintenance steps above does mean a bigger risk of stuff broken, I'd still recommend it in your case right now, simply because it's likely if you tried doing the above in order, you'd have a lot of packages to rebuild in steps 1 and 2 only to support stuff you are removing in step 6. However, if you'd prefer to do the perhaps significant extra work and avoid as much breakage as possible, go ahead and do it this way this time, as well. - revdep-rebuild scans elf files, that is, native elf format binary executables and shared object libraries. While that gets most of the big and critical stuff, revdep-rebuild doesn't understand perl/python/ruby/etc dependencies, and thus won't rebuild them. For those types of things, there are other tools, such as python-updater, for python. - There's another specialized tool for dealing with all those *.la libtool files, helping them find libstdc++, as provided by the gcc package. Every time you unmerge old versions of gcc or when you get libstdc++ errors trying to merge something, you should run fix_libtool_files.sh . Thus, if you just unmerged or it's complaining that it can't find the libstdc++ for gcc-3.4.6, for instance, run fix_libtool_files.sh gcc-3.4.6, and it will scan all the *.la files it can find and ensure all the entries listing that old version also list your current gcc version, as pointed at by gcc-config. Just another tool to know about, as it sure comes in handy sometimes. =8^) - I recommend that folks use FEATURES=buildpkg. That portage feature causes it to build and archive a binary version of every package it merges, by default to $PORTDIR/packages. You can then use emerge --package (-k) or --packageonly (-K) if for some reason you need to remerge an old version of something. This comes in handy in a number of cases, including if you used --depclean and unmerge something that you figure out later you needed, but what wasn't in your world file or listed as a dependency of anything in the world file, for whatever reason. Having a couple old versions around in binary package form is also handy if something stops working right after an upgrade. Having a binary package of gcc around is nice as well, in case gcc breaks, and there are even tricks that allow you to rescue a broken portage or python if you have a binary package, when you'd otherwise be in pretty bad shape, because portage is broken and won't let you emerge a new copy of it! Typically, packages for an entire system take up about a gig, so plan on two gigs or so, just to have a bit of extra room. eclean, now a part of portage, can be used to manage both your packages dir and distdir, pruning old source and package files for ebuilds no longer in the tree. - If you have emerged a lot of library files and other dependencies without using --oneshot, so they ended up in your world file, --depclean won't list or unmerge them when they are no longer needed, because they are in your world file. This is the opposite of the problem above, in that with the above problem, stuff you need isn't in the world file so will be removed by --depclean, while here, stuff you no longer need because it was a dependency of something you are no longer running is listed in the world file, and thus won't be removed. There's a tool to fix this too. =8^) If you know you have this problem, or just want to see if you might, try emerging udept, which contains dep. You can then run dep --pretend --pruneworld, and get a list of entries in your world file that it thinks are depends, and thus removable, since something else in the file depends on them already. There are a bunch of other things it can do as well. It includes its own --depclean implementation, for instance. However, while it's often faster than portage, it's also not always as accurate. Therefore, as usual, --pretend or --ask can be very helpful, and you'll want to treat its results rather more skeptically than you might portage's own. With --pruneworld, for instance, it wanted to remove a couple things from world that I found out later I needed there. Similarly I tried running its depclean, and it wanted to remove QUITE A FEW packages that were needed, and that portage's depclean knew were needed. So it's a tool that helps, and since it's faster, I'll use it for some things, but for things like --depclean, I wouldn't trust it at all, as it DOES get things wrong sometimes, where portage's emerge --depclean gets it right. I'm sure that's more information than you had thought you were asking for, but it's all quite usable here, and hopefully you'll find it equally so there. =8^) -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman -- gentoo-amd64@gentoo.org mailing list