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 1N4zw6-0007zb-DT for garchives@archives.gentoo.org; Mon, 02 Nov 2009 16:39:18 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 263F3E093D; Mon, 2 Nov 2009 16:39:16 +0000 (UTC) Received: from IMPaqm1.telefonica.net (impaqm1.telefonica.net [213.4.129.21]) by pigeon.gentoo.org (Postfix) with ESMTP id 7DB30E093D for ; Mon, 2 Nov 2009 16:39:15 +0000 (UTC) Received: from IMPmailhost3.adm.correo ([10.20.102.124]) by IMPaqm1.telefonica.net with bizsmtp id 0G5J1d0032h2L9m01GfEPw; Mon, 02 Nov 2009 17:39:14 +0100 Received: from jesgue.homelinux.org ([78.136.66.163]) by IMPmailhost3.adm.correo with BIZ IMP id 0GfC1d00D3XLmEe1jGfD5o; Mon, 02 Nov 2009 17:39:14 +0100 X-TE-authinfo: authemail="i92guboj.terra.es" |auth_email="i92guboj@terra.es" X-TE-AcuTerraCos: auth_cuTerraCos="cosuitera01" 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 Date: Mon, 02 Nov 2009 17:39:12 +0100 From: =?UTF-8?Q?Jes=C3=BAs_Guerrero?= To: Subject: Re: [gentoo-user] revdep-rebuild vs. @preserved-rebuild [was: Kmplayer, video and audio not syncing.] In-Reply-To: <200911021650.19528.wonko@wonkology.org> References: <4AE36083.5090005@gmail.com> <200911021612.49295.alan.mckinnon@gmail.com> <4d798132d8d6f64d448147832945a6ba@localhost> <200911021650.19528.wonko@wonkology.org> Message-ID: <68c1fe7a7ee0a17e840b56baccd3ee31@localhost> X-Sender: i92guboj@terra.es User-Agent: RoundCube Webmail/0.3.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Archives-Salt: 33e04ee1-7dff-47d2-9690-ac9589a79001 X-Archives-Hash: 48c91b8583de8dc2614e32683b7641e4 Thanks everyone for the input, it's being quite informative and valuable. I guess I'll have to research on this at some point. Still I'd like to ke= ep responses coming if anyone can bring some light into the issue. :) I am responding only to one post, but I've read Alan's one as well, as said, thanks to everyone that answered. On Mon, 2 Nov 2009 16:50:19 +0100, Alex Schuster wrote: > Jes=C3=BAs Guerrero writes: >=20 >> 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. >=20 > 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 > 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. Ok, well, then the libs are preserved at merge time. Using Alan's analogy= , when you update the lib to y.1.0.1.so. It is *at this time* when y.1.0.0 = is kept, and that has nothing with using "emerge @preserved-rebuild" *in the future*. You could still use revdep-rebuild and the effect will be the sa= me (except that old libs will not ever be cleaned if I got it right). Right? So, it's not "emerge @preserved-rebuild" which fixes the problem (as I said, by the time you run "emerge @preserved-rebuild" it's already too late, by then the libs are either preserved or broken), but a whole new portage behavior, which is quite different. And maybe only if you have a given FEATURE enabled, which takes this even more far away from the @revdep-rebuild set. So, if this all is correct, this set is intended to *fix* the breakage, just like revdep-rebuild, and *not to prevent* it. It's portage which prevents it by preserving all .so files. Note that revdep-rebuild didn't break anything either. That's false. revdep-rebuild only fixes what porta= ge breaks. It all comes down to one thing: are you using the preserve featur= e or not? And not the tool you use to fix the binaries. >=20 >> >> > 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 time= s >> >> 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 fin= d >> >> 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. >=20 > I had the same problem with emerge @preserved-rebuild looping endlessly= , > 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. That's good to know. However this needs to be fixed, which is probably on= e of the reasons why portage 2.2 is taking quite a bit to be released. >> >> > 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 th= e >> 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. >=20 > Again, things do not break in the first place with the preserved-rebuil= d > FEATURE. As a library gets updated, the new library is installed along > with=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 librarie= s > obsolete when this is done for all packages depending on them. >=20 >> I mean: if the old libs with the old abi's are kept, how it is relevan= t >> if you are using @preserved-rebuild, revdep-rebuild or another method= , >> or none at all? Your programs will continue to work ok without needin= g >> 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. >=20 > I think the revdep-rebuild way would not work here. I assume it uses ld= d > to=20 > check all binaries for existance of their libraries, and rebuild them i= f > 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. Thanks, these two paragraphs seem to confirm my thoughts above. I finally understand what this is about :) --=20 Jes=C3=BAs Guerrero