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 <wo...@wonkology.org> wrote: > 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. 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
