From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1N4zBM-0003Qy-0W for garchives@archives.gentoo.org; Mon, 02 Nov 2009 15:51:00 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id AC8CBE0828; Mon, 2 Nov 2009 15:50:26 +0000 (UTC) Received: from mail.askja.de (mail.askja.de [83.137.103.136]) by pigeon.gentoo.org (Postfix) with ESMTP id 87351E0828 for ; Mon, 2 Nov 2009 15:50:26 +0000 (UTC) Received: from static-87-79-89-40.netcologne.de ([87.79.89.40] helo=zone.wonkology.org) by mail.askja.de with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1N4zAo-0003OH-2F for gentoo-user@lists.gentoo.org; Mon, 02 Nov 2009 16:50:26 +0100 Received: from localhost (localhost [127.0.0.1]) (uid 1000) by zone.wonkology.org with local; Mon, 02 Nov 2009 16:50:21 +0100 id 00010341.4AEEFFBD.000061F2 From: Alex Schuster To: gentoo-user@lists.gentoo.org Subject: Re: [gentoo-user] revdep-rebuild vs. @preserved-rebuild [was: Kmplayer, video and audio not syncing.] Date: Mon, 2 Nov 2009 16:50:19 +0100 User-Agent: KMail/1.12.2 (Linux/2.6.31-tuxonice; KDE/4.3.2; i686; ; ) References: <4AE36083.5090005@gmail.com> <200911021612.49295.alan.mckinnon@gmail.com> <4d798132d8d6f64d448147832945a6ba@localhost> In-Reply-To: <4d798132d8d6f64d448147832945a6ba@localhost> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@lists.gentoo.org Reply-to: gentoo-user@lists.gentoo.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: <200911021650.19528.wonko@wonkology.org> X-Archives-Salt: 6ddd751a-2762-4117-9615-a43caa918844 X-Archives-Hash: 821bb30d38b3006cb085ffb4e106b91d Jes=C3=BAs Guerrero writes: > On Mon, 2 Nov 2009 16:12:49 +0200, Alan McKinnon > wrote: > > On Monday 02 November 2009 15:58:57 Jes=C3=BAs Guerrero wrote: > >> On Mon, 2 Nov 2009 13:25:08 +0000, Neil Bothwick > >> wrote: > >> > On Mon, 02 Nov 2009 13:58:03 +0100, Jes=C3=BAs Guerrero wrote: > >> >> @preserved-rebuild never worked for me, maybe it's just that it > >> >> doesn't like ~arch. I am just too lazy to work on how to fix a > >> >> thing when there's an alternative that always worked reliably, > >> >> revdep-rebuild. I like the preserve-libs FEATURE. With revdep-rebuild, things are fixed=20 after they were broken by an update of a library. And there is a time (in=20 case of the dreaded expat update, a large one, expecially if revdep- rebuilding stuff fails for some packages) in which things do not work. I=20 always hated that and considered it a serious bug. With preserve-libs, things do not break in the first place, because the old= =20 libraries are still in place. > >> > If it didn't work on ~arch, how would it ever make it into arch? > >> > >> I am not the one to answer that, all I can say is that the few times > >> I've tried it, it kept rebuilding the same packages again, and=20 > >> again, and again ad infinitum, as said, I didn't even bother to find > >> what the problem was, because I have a working alternative. Sure it > >> could be better, but that hasn't been the case for me with=20 > >> @preserved-rebuild. I had the same problem with emerge @preserved-rebuild looping endlessly,=20 but that's probably just a minor issue. Just use emerge @preserved-rebuild= =20 once to make sure the new libs are being used, and remove=20 /var/lib/portage/preserved_libs_registry afterwards to get rid of the=20 preserved-libs message. > >> > The trouble with revdep-rebuild is that you have to break your > >> > system and then fix it. Most of the time this is trivial, but > >> > updates like expat-2.0 showed the usefulness of being able to > >> > recompile the packages before they were broken. > >> > >> I can't understand that. You CAN'T recompile your packages against > >> the new ABI's until the new ABI is in your system, and hence your > >> system is already broken. There's no preemptive measure against > >> this. Both methods fix the system *after* it's broken. > > > > Unless the old and the new ABI version are installed side by side. When > > @preserved-rebuild is run, it deletes the old libs only after > > everything left that used it is now linked against the new one. >=20 > Thanks for the feedback. However there's one thing I can't understand: > whether the libraries are kept of removed is decided at the merge time, > isn't it? So, whatever breaks, breaks when using "emerge" to update the > offending library, the one that will break the ABI. So, how can using a > tool *after that* have any impact over what's broken? It can fix the > problem, but so can revdep-rebuild. Again, things do not break in the first place with the preserved-rebuild=20 =46EATURE. As a library gets updated, the new library is installed along wi= th=20 the old one. Applications linked to the old one still work. When they are=20 re-compiled, the are linked to the new library, making the old libraries=20 obsolete when this is done for all packages depending on them. > I mean: if the old libs with the old abi's are kept, how it is relevant > if you are using @preserved-rebuild, revdep-rebuild or another method, > or none at all? Your programs will continue to work ok without needing > to rebuild anything, won't them? And after rebuilding the package it's > irrelevant *how* did you rebuild them... I must obviously be missing > something here, if you have the time please, direct me to an adequate > source of information or explain a bit, I am curious. I think the revdep-rebuild way would not work here. I assume it uses ldd to= =20 check all binaries for existance of their libraries, and rebuild them if=20 there are problems. When the old libraries are still in place, there is no= =20 problem for ldd, and nothing gets re-compiled. No big problem, but you=20 clutter your system with old libraries staying in place, and programs still= =20 using them do not take possible advantage ob the newer libraries. Wonko