Josh Sled <js...@asynchronous.org> posted 874oup4k11....@phoenix.asynchronous.org, excerpted below, on Tue, 09 Jun 2009 09:24:42 -0400:
> Duncan <1i5t5.dun...@cox.net> writes: >> It's not going to be of much help at the moment, but FWIW, upgrades do >> tend to go much smoother if you don't stay away from them so long. >> Personally, I try to do them twice a week > > I like weekly ... it's easier to integrate into my schedule (where most > recurring tasks are weekly) as a Thursday morning task. I like later in > the week, as well, so that if things do go pear-shaped, I have the > weekend to recover, minimizing work disruption. That makes sense. > Also, I'd advise against running `emerge --depclean` blind. Either run > it with '-pv' and review the output, or run with '--ask' ... though the > former is suited better to my "background batch" mode of doing upgrades > while working. I can't quantify or even really qualify it, but I've > seen --depclean outright lie. :( The key to working with depclean is understanding how it works. All it does is work backward from the list of packages in world, using the dependencies those ebuilds claim, the dependencies of the dependencies, etc, all the way down. Similarly it checks the system set as determined by your profile. Certain dependencies are conditional in the ebuild based on USE flags. That's why it's important to do an emerge -N (--newuse) before doing a depclean and after changing USE flags, since depclean uses the USE flag configuration to figure out dependencies and if the USE flags and therefore calculated dependencies a package was built and installed with get changed, depclean will change its dependency calculation accordingly, and if the actual package hasn't been remerged to reflect the change, that can break stuff. Similarly but less so with -D (--deep). The scripts I use to do updates with include -NuD by default, so if anything changes, I'm told about it and the updates that might otherwise be missed are taken care of. Thus, when I'm done with an update session (weekly as you mentioned is great, here as I said it's usually 2-3 times a week, very seldom more than five days), all deep dependencies are already reconciled as are any USE flag changes, whether I made them or the Gentoo devs made them in the ebuilds. Then I do a revdep-rebuild (-p/--pretend), which looks at the actual ELF binaries, checking that the libraries they say they need are available, telling me which packages, if any, need rebuilt to ensure that the libraries are there. Normally, I take the revdep-rebuild pretend output and remerge anything that it lists manually, rather than letting revdep-rebuild do it for me. Don't forget to add the -1/--oneshot (which the scripts I use do by default) to keep dependencies out of the world file if you do the emerges manually, tho. Handling it manually keeps me more in tune with the system, so I know better what's going on. After some experience, I know for instance that anytime I update a codec, stuff like transcode, which depends on codecs by definition, is likely to need rebuilt. transcode updates in turn often trigger k3b rebuilds. Thus, I now know to expect such things when I first see the updates show up in my first emerge -NuDp @world after syncing, before I've even actually done anything, and well before I've run the post-update revdep-rebuild -p. Once the rebuilds are done, I run an emerge --depclean (-p), to see what portage thinks of the dependency tree. Since I keep up with things and there was normally nothing in the depclean list when I was finished the last time, unless an update I just finished changed dependencies or I deliberately unmerged something previously in world, there will still be nothing in it. If a dependency changed, no big deal, I simply check it for sanity (occasionally a package maintainer will make a mistake and a dependency won't be listed in the ebuild, remember, it's the ebuild dependencies that depclean uses, unlike revdep-rebuild, it doesn't check the actual files), and normally remove it, again, usually manually. Alternatively, if I think it should be needed, I'll add it to my world file using emerge --noreplace. There's one exception. Since I normally keep my depclean list clean and my normal merge scripts all use -1, any new packages (IOW, not updates, first-time installs or reinstalls after having them off the system for awhile) I just merged normally shows up in the depclean list (because I used -1/--oneshot) to be removed. That's fine and actually the way I want it, because what it effectively does is give me a "trial install" feature. I can try out my new toys and decide whether I want to keep them. If I like them, I use emerge --noreplace to add them to the world file (just adding them to world, no remerge, that's what noreplace does). If I decide I don't like them, I either unmerge them directly or let depclean (without the -p now) do its thing. After the depclean (either without -p or manually unmerging what it listed), the list of installed packages has changed, so another revdep- rebuild is called for, to verify that the system is still self- consistent. Usually it is, because the --newuse or first revdep-rebuild will have triggered a rebuild of anything that wouldn't be. However, occasionally there will have been what Gentoo devs term an "automagic dependency". These are a hassle for both users (when things break as a result) and devs (finding and fixing them). They result when a package's pre-build configure scripts detect whether something's installed and build against it if it is, regardless of what the ebuild dependencies say. As they catch such automagic detection, Gentoo devs will change the parameters they feed to the configure scripts or if necessary patch the package, taking away the automagic dependency and either hard-wiring it on or off, or more normally, binding it to a USE flag, so the dependencies are deterministic and all actual dependencies are reflected in the ebuild dependencies. Anyway, that's what this last revdep-rebuild (-p) does, catching any automagic dependencies that weren't reflected in the ebuild, listing the broken packages so I can remerge them. Again, I normally use -p and get a list, then take care of it manually, thus allowing me to stay rather closer and more in tune with the system I'm managing. When I'm done, with the possible exception of any packages I'm still testing and haven't decided whether to keep or not, all of the following return no packages: emerge -NuDp @system, emerge -NuDp @world, emerge --p --depclean, revdep-rebuild -p. By the time I do my next update in a few days, I will have normally decided whether to keep or remove any "trialware", and will either add it to world (using emerge --noreplace) or unmerge it (using emerge -C or emerge --depclean). If for some reason I forget, the routine depclean at the end of /that/ session will remind me, and I can do something about it then, double-checking when I'm done that all of the above now return no packages to update, remerge, add to world or remove. Anyway, looked at that way, --depclean does not lie. It's simply going by what the ebuilds say are the dependencies, and by what's in @system and @world. If they are wrong, it's wrong. No more, no less. And for someone who keeps their system properly maintained, so nothing shows up in update, rebuild or remove lists at the end of every update session, any changes to that "nothing" are immediately obvious. That's also another reason for frequent syncs and updates, because if only a half- dozen packages were there to update after the sync (or many, but all say kde but one or two), it's often pretty obvious what package is screwed up when suddenly depclean decides a dependency or two is no longer needed, and I can file bugs appropriately. (Of course, this is more likely to happen for ~arch users such as myself, constantly testing the newer packages, than it should for stable users, but nobody including no Gentoo devs, are perfect.) >> I do hope gcc-config does it for you. Otherwise, I'm getting a bit >> worried, as if man is broken, it's reaching pretty far into your >> system. Please post updates as you have them, because I /am/ a bit >> worried, now. > > Another option might be to get the removed version (gcc-4.3, I believe) > re-installed by hell or high-water, re-establishing the missing/broken > bits. Hopefully it'll build clean with 4.4, or maybe you can find a > quickpkg/binpackage from someone with a sufficiently-similar config. I > recently removed an older gcc that --depclean reported unneeded, and had > breakage ... I noticed it almost immediately, and was able to get back > to a working system with a minimum of fuss. That's what the FEATURES=buildpkg feature is there for. =:^) With it on, once the system has been rebuilt with it once, any time there's an update, both the old and new versions are now available as binpkgs for reinstall, should the need appear. =:^) I've said it before and I'll say it again, FEATURES=buildpkg really is my favorite under-publicized portage feature. Years after I first discovered it I'm still amazed at just how may tricks it makes possible, how many binds it can help get one out of -- and yet how little time is actually spent on it in the various documentation. -- 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
