Jesús Guerrero writes:
> On Mon, 2 Nov 2009 16:12:49 +0200, Alan McKinnon
> <alan.mckin...@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 <n...@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.
> >> > 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.
> >> > 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.
Wonko
