Re: [gentoo-user] revdep-rebuild vs. @preserved-rebuild [was: Kmplayer, video and audio not syncing.]
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 +, 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. 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. -- Jesús Guerrero
Re: [gentoo-user] revdep-rebuild vs. @preserved-rebuild [was: Kmplayer, video and audio not syncing.]
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 +, 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
Re: [gentoo-user] revdep-rebuild vs. @preserved-rebuild [was: Kmplayer, video and audio not syncing.]
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 +, 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
Re: [gentoo-user] revdep-rebuild vs. @preserved-rebuild [was: Kmplayer, video and audio not syncing.]
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 +, 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
