On Monday 02 November 2009 17:01:17 Jesús Guerrero wrote: > 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. > >> > > >> > 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'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 > > installations. > > >> > 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. > > 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.
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 thinks to itself "hang on a bit, I'm about to remove a library that Y is using. I'd better not do that!" and tells you so. (In the meantime you can merge anything 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 library. When everything in @preserved-rebuild has been rebuilt, portage knows 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 libs are not missing? And that @preserved-rebuild and revdep-rebuild do essentially 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 run It can go south sometimes, the @preserved-rebuild magic is not always perfect and sometimes it gets confused. There's a file in /var somewhere that records this, so you can just delete it and run revdep-rebuild to get the old behaviour. Sometimes devs do stupid things with what they decide libs are called, and there's nothing portage can do about that except get itself 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 than a year now?) with very very few hitches. I think you were just unlucky to 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. > > Of course, I can understand that. > > 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 that > I'm not complaining, merely describing my experience, I'd rather be filling > 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. yes, the old way does work. But it has this period in the middle where stuff is broken. Preserved-rebuild is an effort to do the same thing in a different order, to minimize breakage Of course, my entire understanding of this could be completely wrong. If so, someone will correct me :-) -- alan dot mckinnon at gmail dot com
