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

On Monday 02 November 2009 17:01:17 Jes=C3=BAs Guerrero wrote:
> On Mon, 2 Nov 2009 16:12:49 +0200, Alan McKinnon
>=20
> 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.
> >> >
> >> > 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
>=20
> I've
>=20
> >> 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
>=20
> was,
>=20
> >> because I have a working alternative. Sure it could be better, but that
> >> hasn't been the case for me with @preserved-rebuild.
> >>
> >> I've seen people reporting the same problems in the forums, so I am
> >> fairly
> >> sure that's a common problem and not just exclusive to my
>=20
> installations.
>=20
> >> > 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
>=20
> the
>=20
> >> 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.
>=20
> 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 no=
ne
> 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 informati=
on
> or explain a bit, I am curious.
Easy. Say you have app x which links to lib y:
portage knows that x is linked to say y.1.0.0.so
portage then upgrades y and puts y.so.1.0.1.so and the system helpfully thi=
nks=20
to itself "hang on a bit, I'm about to remove a library that Y is using. I'=
d=20
better not do that!" and tells you so. (In the meantime you can merge anyth=
ing=20
you like that links to y.1.0.0.so, this does not affect @preserved-rebuild)
You read the message, run @preserved-rebuild and x now links to the new y=20
library. When everything in @preserved-rebuild has been rebuilt, portage kn=
ows=20
that now nothing links to the old y library, and removes it.
Do you see that the intent is to provide a bridging period where needed lib=
s=20
are not missing? And that @preserved-rebuild and revdep-rebuild do essentia=
lly=20
the same function, except:
1. Stuff does not break. OK, make that "stuff should not break"
2. You don't have to hang around waiting for revdep-rebuild to take ages to=
=20
run
It can go south sometimes, the @preserved-rebuild magic is not always perfe=
ct=20
and sometimes it gets confused. There's a file in /var somewhere that recor=
ds=20
this, so you can just delete it and run revdep-rebuild to get the old=20
behaviour. Sometimes devs do stupid things with what they decide libs are=20
called, and there's nothing portage can do about that except get itself=20
confused (it's not a human and can't infer meaning).
I've been using @preserved-rebuild for as long as it's been available (more=
=20
than a year now?) with very very few hitches. I think you were just unlucky=
to=20
hit a few stupid packages.
> > There's only one case where this can't work - the developer changes the
> > ABI
> > and does not change the .so version number. That ain't gentoo's fault -
> > shoot
> > the developer.
>=20
> Of course, I can understand that.
>=20
> However and even if @preserved-rebuild has some reason to exist, it still
> doesn't fix the weird behavior that it exhibited for me in the past. But =
to
> tell the truth, I haven't tested lately. It just came to mi mind because =
of
> the Dale's problem, which seems to be the same one. Please, understand th=
at
> I'm not complaining, merely describing my experience, I'd rather be filli=
ng
> bugs than complain uselessly, it's just that -as I said- I really didn't
> see a need to because the old way just works.
=20
yes, the old way does work. But it has this period in the middle where stuf=
f=20
is broken.=20
Preserved-rebuild is an effort to do the same thing in a different order, t=
o=20
minimize breakage
Of course, my entire understanding of this could be completely wrong. If so=
,=20
someone will correct me :-)
=2D-=20
alan dot mckinnon at gmail dot com