Tom Wijsman posted on Thu, 02 May 2013 07:09:10 +0200 as excerpted: > Duncan <1i5t5.dun...@cox.net> wrote: > >> After some early issues with "too much magic" re preserved-libs > > Why is it magic? It is well explained what it does (eg. man make.conf). > >> I originally would rather let the upgrades happen as they always did >> and simply run revdep-rebuild afterward > > You know that if you enable preserve-libs that you have to instead run > `emerge @preserved-rebuild`, which has a much shorter runtime. > >> and preserved-libs interfered with that as the libs were still there so >> revdep-rebuild didn't find anything to rebuild. > > `emerge @preserved-rebuild` will find and rebuild them.
To those who say I'm too verbose, this is what happens when I try to shortcut things... I invariably end up spelling it all out anyway in a followup, when someone doesn't understand the shortcut and needs the full explanation... It happens frequently enough that I had learned to avoid it by covering what I could the first time around. Now with some friendly urging, I'm trying to unlearn that, but... Just sayin'... Yes. I understand all about @preserved-libs and was in fact an early feature tester... which is actually likely part of the problem. The problem, which as I said earlier I expect has long since been fixed, was in the "magic" bit of old libraries being temporarily reassigned as owned by the newer versions that replaced them, even tho they weren't actually part of that version of the package at all, but a previous version. What happened was that the emerge @preserved-libs failed for some reason, leaving some of these stale libs that had been artificially reassigned as owned by the new version, now owned by no one and untracked. But because they were still there, revdep-rebuild wouldn't detect the problem, and because they were now orphaned, I couldn't find them by looking at the files owned by the new versions, so I was a bit stuck. Fortunately in that instance I had only updated a few packages that I had to go manually comparing old binpkg contents with new binpkg contents to track down the orphan libs to delete manually, after which revdep-rebuild worked as it should, but I decided that was "too much magic" to rely on in the future, when the old remove it and let revdep- rebuild detect and handle the resulting rebuilds was a well proven method that "just worked". "Magic" in this case being defined simply as too much hassle for me to figure out what it did manually and fix things up when it screwed up, when there was a well tested tool that might be a bit slower, but that uses a method known to be /very/ reliable at finding and fixing the sort of library-dependency issues it dealt with. Meanwhile, revdep-rebuild isn't /that/ slow. As I found out by experience, it's MUCH faster than rooting out problems manually when @preserved-libs fails its "magic" for whatever reason. Actually, most of the wait on revdep-rebuild on conventional/legacy "spinning rust" systems is due to the I/O latency of actually reading in all the files it scans. Which is quite convenient, since it only needs run after a normally heavily CPU bound world update... such that an I/O bound process conveniently runnable at the same time won't significantly slow down either one! =:^) For those with sufficient memory (@16 gigs I rarely zero-out free memory and dump cache), simply start the emerge update, then in another VT or terminal window, start an initial revdep- rebuild --pretend. By the time the update is done, the revdep-rebuild has generally finished as well, so all the files it scans are in cache. And with a hot cache, revdep-rebuild runs **MUCH** faster the second time around, after the update's done so any needed rebuilds can actually be detected and the rebuild done. =:^) I generally run the emerge --jobs --update..., then run the revdep- rebuild in parallel, since the first is generally CPU bound and the second disk bound. Then when the update is done, I run revdep-rebuild for-real this time, while running etc-update and emerge --ask --depclean (serially) in the other terminal. By the time the etc-update and depclean are done, the (hot-cached) revdep-rebuild is generally done too (thanks to being run routinely so there's never a backlog, and thanks to lddflags as-needed and now subslots as well, taking away most of the work revdep- rebuild used to need to do), so it really didn't take me much more time at all, since otherwise I'd have been waiting first on the update, and then would have been managing the etc-update and waiting on the depclean. Meanwhile, I've finally decided it's time to leave the legacy spinning- rust world behind (for the frequently accessed stuff like the OS, much of /home, and the tree, anyway) and should be upgrading to SSDs soon. With luck, that'll solve much of the current spinning rust latency bottlenecks, leaving me an entirely new set of bottlenecks to learn to to deal with and attempt to optimize around... (I've tried btrfs already, I think I'll try f2fs on the SSDs, while the spinning rust I'll be copying over from is still current enough to serve as a good backup in case anything goes wrong...) -- 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
