[gentoo-dev] Re: RANT: Upgrade icu and KDE at once
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
[gentoo-dev] Re: RANT: Upgrade icu and KDE at once
Hi Zac,
Zac Medico wrote:
On Tue, Apr 30, 2013 at 9:51 AM, Jörg Schaible joerg.schai...@gmx.de
wrote:
The most annoying fact is, that none of this would have been necessary
with portage 2.2, but maybe we have to wait for 2.1.11.500 before 2.2
gets stable...
Since portage-2.1.11.20 [1], you can do this:
echo 'FEATURES=${FEATURES} preserve-libs' /etc/portage/make.conf
[1]
[http://blogs.gentoo.org/zmedico/2012/09/21/preserve-libs-available-in-portage-2-1/
That announcement slipped somehow my awareness. Indeed an upgrade of a
different machine with preserve-libs added to FEATURES went fine. Still, I
wonder what prevents portage-2.2 form going stable, I have one machine where
I use that one for years without any flaws and a lot of benefits.
- Jörg
Re: [gentoo-dev] Re: RANT: Upgrade icu and KDE at once
On 05/01/2013 02:07 AM, Jörg Schaible wrote:
Hi Zac,
Zac Medico wrote:
On Tue, Apr 30, 2013 at 9:51 AM, Jörg Schaible joerg.schai...@gmx.de
wrote:
The most annoying fact is, that none of this would have been necessary
with portage 2.2, but maybe we have to wait for 2.1.11.500 before 2.2
gets stable...
Since portage-2.1.11.20 [1], you can do this:
echo 'FEATURES=${FEATURES} preserve-libs' /etc/portage/make.conf
[1]
[http://blogs.gentoo.org/zmedico/2012/09/21/preserve-libs-available-in-portage-2-1/
That announcement slipped somehow my awareness. Indeed an upgrade of a
different machine with preserve-libs added to FEATURES went fine. Still, I
wonder what prevents portage-2.2 form going stable, I have one machine where
I use that one for years without any flaws and a lot of benefits.
I think it's more useful to talk about specific features and their
readiness to be enabled by default in stable, rather then when
everything in portage-2.2 should go stable. Which features in
portage-2.2 are you using that are ready for stable?
Not that the difference between portage-2.1 and portage-2.2 is just the
constants that you can see in this commit:
http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=92ce3fcbf2c6d791151afc6edbbb18a530db12e2
--
Thanks,
Zac
[gentoo-dev] Re: RANT: Upgrade icu and KDE at once
Zac Medico posted on Wed, 01 May 2013 08:01:45 -0700 as excerpted: On 05/01/2013 07:46 AM, Mike Gilbert wrote: I think it is time to consider enabling [preserve-libs] by default. Hopefully any ABI bumps will be accompanied by a subslot / slot-operator migration at this point. Yeah, I'm pretty happy with the slot-operator adoption, so it feels like it's about time to enable preserve-libs by default in stable. I know that this feature has been questioned by some, especially by people involved with Paludis (which doesn't implement preserve-libs). Maybe it would be a good idea to get an opinion from the council on whether or not it should be enabled by default in stable portage. FWIW I've been running 2.2 (and won't touch paludis with a 3 metre pole) for some time, but turned preserved-libs off here because it simply complicates things for me. After some early issues with too much magic re preserved-libs (possibly long since fixed but I wouldn't know as I have the feature turned off), I originally would rather let the upgrades happen as they always did and simply run revdep-rebuild afterward, and preserved-libs interfered with that as the libs were still there so revdep-rebuild didn't find anything to rebuild. Of course with sub-slots doing it the 'correct' way revdep-rebuild isn't finding so much to rebuild anymore, anyway, so like most people I think, I'm a big subslots fan, but that doesn't mean I trust preserved- libs any more than I did. But I've no objection to preserved-libs becoming the default and while it's not for me personally, I'm cautiously in favor of the idea as a default, as long as it remains a togglable feature. While I /am/ cautiously in favor, I definitely believe running it by council is a good idea, as it should help put to bed any remaining controversy over the idea. Neither the formal speak now or forever hold your peace aspect nor the CYA and it's voted and settled now, don't reopen the topic unless there's GOOD reason a council blessing provides can be a bad thing. =:^) -- 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
Re: [gentoo-dev] Re: RANT: Upgrade icu and KDE at once
On Thu, 2 May 2013 03:38:24 + (UTC) 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. -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
