Re: [gentoo-user] revdep-rebuild vs. @preserved-rebuild [was: Kmplayer, video and audio not syncing.]

["Jesús Guerrero" <i92guboj@terra.es>]

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 keep
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 <wonko@wonkology.org>
wrote:
> Jesús Guerrero writes:
> 
>> On Mon, 2 Nov 2009 16:12:49 +0200, Alan McKinnon
>>  <alan.mckinnon@gmail.com> wrote:
>> > On Monday 02 November 2009 15:58:57 Jesús Guerrero wrote:
>> >> On Mon, 2 Nov 2009 13:25:08 +0000, Neil Bothwick
<neil@digimed.co.uk>
>> >> wrote:
>> >> > On Mon, 02 Nov 2009 13:58:03 +0100, Jesús 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 
> after they were broken by an update of a library. And there is a time
(in 
> 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 
> 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 same
(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 portage
breaks. It all comes down to one thing: are you using the preserve feature
or not? And not the tool you use to fix the binaries.

> 
>> >> > 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 
>> >> 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 
>> >> @preserved-rebuild.
> 
> I had the same problem with emerge @preserved-rebuild looping endlessly,

> but that's probably just a minor issue. Just use emerge
@preserved-rebuild 
> once to make sure the new libs are being used, and remove 
> /var/lib/portage/preserved_libs_registry afterwards to get rid of the 
> preserved-libs message.

That's good to know. However this needs to be fixed, which is probably one
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.
>> 
>> 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

> FEATURE. As a library gets updated, the new library is installed along
> with 
> the old one. Applications linked to the old one still work. When they
are 
> re-compiled, the are linked to the new library, making the old libraries

> 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 
> check all binaries for existance of their libraries, and rebuild them if

> there are problems. When the old libraries are still in place, there is
no 
> problem for ldd, and nothing gets re-compiled. No big problem, but you 
> clutter your system with old libraries staying in place, and programs
> still 
> 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 :)

-- 
Jesús Guerrero