Re: [gentoo-user] Re: Updating libpng: another lib tool cockup?
On Mon, 19 Sep 2011 13:57:03 -0400, Allan Gottlieb wrote: When revdep-rebuild --library is suggested should we run it before or after the ordinary revdep-rebuild that we typically run after each update world? (That was actually my original question :-) You should run it first, because the elog message is telling you to run that command, not revdep-rebuild, which is usually unnecessary. The reason revdep-rebuild alone finds nothing to rebuild is because portage has ensured that nothing is broken by preserving the old library version. With a recent enough portage, emerge @preserved-rebuild should avoid the need for revdep-rebuild entirely, although in this case it doesn't quite manage that. -- Neil Bothwick WinErr 004: Erroneous error - Nothing is wrong signature.asc Description: PGP signature
Re: [gentoo-user] Re: Updating libpng: another lib tool cockup?
On Tue, Sep 20 2011, Neil Bothwick wrote: On Mon, 19 Sep 2011 13:57:03 -0400, Allan Gottlieb wrote: When revdep-rebuild --library is suggested should we run it before or after the ordinary revdep-rebuild that we typically run after each update world? (That was actually my original question :-) You should run it first, because the elog message is telling you to run that command, not revdep-rebuild, which is usually unnecessary. The reason revdep-rebuild alone finds nothing to rebuild is because portage has ensured that nothing is broken by preserving the old library version. With a recent enough portage, emerge @preserved-rebuild should avoid the need for revdep-rebuild entirely, although in this case it doesn't quite manage that. Thank you. allan
Re: [gentoo-user] Re: Updating libpng: another lib tool cockup?
On Mon, Sep 19 2011, Michael Schreckenbauer wrote: On Monday, 19. September 2011 10:20:25 Allan Gottlieb wrote: On Mon, Sep 19 2011, Alan McKinnon wrote: revdep-rebuild checks everything, revdep-rebuild --library checks just some things. ebuilds sometimes issue messages to check just the libraries known to have been updated, but a full revdep-rebuild after an update will catch those anyway. Until recently I skipped the --library step exactly because I knew revdep-rebuild will find and fix the broken packages after I delete the old library. So, why bother with the --library step, right? However. A few weeks ago I got caught when I deleted one of those obsolete libraries and only then did I find out that gcc is one of the packages that depend on it :( I don't skip the --library step any more. That's odd behaviour, I wonder what caused the difference. Surely revdep-rebuild itself can't do this different just because you specified a library to compare? I wonder if that lib was maybe in the revdep-rebuild exclude list. I'd be interested to track it down for reference, do you remember the library involved? It occurs exactly in the case we are discussing libpng ajglap gottlieb # revdep-rebuild; revdep-rebuild --library '/usr/lib64/libpng14.so.14' * Configuring search environment for revdep-rebuild * Checking reverse dependencies * Packages containing binaries and libraries broken by a package update * will be emerged. ... * Checking reverse dependencies * Packages containing binaries and libraries using /usr/lib64/libpng14.so.14 * will be emerged. First one emerges *broken* packages. Second one emerge packages *using* png14 (not necessarily broken) OK. But the claim was that: if revdep-rebuild with no argument found nothing to build, then revdep-rebuild --library some-library will find nothing. This guarantee is apparently no long true as my example in another msg illustrated. allan
Re: [gentoo-user] Re: Updating libpng: another lib tool cockup?
On Monday, 19. September 2011 10:58:52 Allan Gottlieb wrote: On Mon, Sep 19 2011, Michael Schreckenbauer wrote: On Monday, 19. September 2011 10:20:25 Allan Gottlieb wrote: On Mon, Sep 19 2011, Alan McKinnon wrote: revdep-rebuild checks everything, revdep-rebuild --library checks just some things. ebuilds sometimes issue messages to check just the libraries known to have been updated, but a full revdep-rebuild after an update will catch those anyway. Until recently I skipped the --library step exactly because I knew revdep-rebuild will find and fix the broken packages after I delete the old library. So, why bother with the --library step, right? However. A few weeks ago I got caught when I deleted one of those obsolete libraries and only then did I find out that gcc is one of the packages that depend on it :( I don't skip the --library step any more. That's odd behaviour, I wonder what caused the difference. Surely revdep-rebuild itself can't do this different just because you specified a library to compare? I wonder if that lib was maybe in the revdep-rebuild exclude list. I'd be interested to track it down for reference, do you remember the library involved? It occurs exactly in the case we are discussing libpng ajglap gottlieb # revdep-rebuild; revdep-rebuild --library '/usr/lib64/libpng14.so.14' * Configuring search environment for revdep-rebuild * Checking reverse dependencies * Packages containing binaries and libraries broken by a package update * will be emerged. ... * Checking reverse dependencies * Packages containing binaries and libraries using /usr/lib64/libpng14.so.14 * will be emerged. First one emerges *broken* packages. Second one emerge packages *using* png14 (not necessarily broken) OK. But the claim was that: if revdep-rebuild with no argument found nothing to build, then revdep-rebuild --library some-library will find nothing. This is not true. revdep-rebuild without --library argument checks for packages with *broken* linking, eg a library changed it's name and the original one was removed by an update. revdep-rebuild --library checks for packages using that library. If the first one returns nothing, that means, your linking is all ok. If the second one returns nothing, it tells you, that nothing is using that library at all. This guarantee is apparently no long true as my example in another msg illustrated. I doubt it was true in the past. Best, Michael
Re: [gentoo-user] Re: Updating libpng: another lib tool cockup?
On Mon, 19 Sep 2011 10:58:52 -0400 Allan Gottlieb gottl...@nyu.edu wrote: First one emerges *broken* packages. Second one emerge packages *using* png14 (not necessarily broken) OK. But the claim was that: if revdep-rebuild with no argument found nothing to build, then revdep-rebuild --library some-library will find nothing. This guarantee is apparently no long true as my example in another msg illustrated. Michael is indeed correct. A careful reading of the man page reveals the usage of the words broken and using exactly like he said. So I stand humbly corrected. I find revdep-rebuild's behavior in this respect confusing. Even though it is clearly documented it is unexpected. It would never have occurred to me to draw that distinction. -- Alan McKinnnon alan.mckin...@gmail.com
Re: [gentoo-user] Re: Updating libpng: another lib tool cockup?
On Monday, 19. September 2011 17:28:26 Alan McKinnon wrote: On Mon, 19 Sep 2011 10:58:52 -0400 Allan Gottlieb gottl...@nyu.edu wrote: First one emerges *broken* packages. Second one emerge packages *using* png14 (not necessarily broken) OK. But the claim was that: if revdep-rebuild with no argument found nothing to build, then revdep-rebuild --library some-library will find nothing. This guarantee is apparently no long true as my example in another msg illustrated. Michael is indeed correct. A careful reading of the man page reveals the usage of the words broken and using exactly like he said. So I stand humbly corrected. I find revdep-rebuild's behavior in this respect confusing. Even though it is clearly documented it is unexpected. It would never have occurred to me to draw that distinction. I think, it is very useful. An example: $ ldd /bin/bash linux-vdso.so.1 = (0x7fffbafff000) libncurses.so.5 = /lib64/libncurses.so.5 (0x7f0a4c278000) libdl.so.2 = /lib64/libdl.so.2 (0x7f0a4c074000) libc.so.6 = /lib64/libc.so.6 (0x7f0a4bce4000) /lib64/ld-linux-x86-64.so.2 (0x7f0a4c4ce000) Assume ncurses get's an update (new version is libncurses.so.6) Now if portage decided to *remove* libncurses.so.5 during that update, my bash would be broken. Very bad, so the ebuild-writer decides to leave libncurses.so.5 on my system. Because linking of bash is consistent (it still links to .so.5) a run of revdep-rebuild without args would return without result. With revdep-rebuild --library libncurses.so.5 I am now able to find and rebuild all packages, that use the ancient version of ncurses and after that, I can *safely* remove it. Best, Michael
Re: [gentoo-user] Re: Updating libpng: another lib tool cockup?
On Mon, Sep 19, 2011 at 9:58 AM, Allan Gottlieb gottl...@nyu.edu wrote: OK. But the claim was that: if revdep-rebuild with no argument found nothing to build, then revdep-rebuild --library some-library will find nothing. I think what everyone (except Michael S) seems to be confused about is: Normal revdep-rebuild (with no options) looks for broken shared library dependencies and rebuilds them. If you run it again, it won't rebuild anything, because the dependency has been fixed. Using the --library switch, however, it looks for everything built against that library, regardless of whether or not the dependency is broken, and rebuilds it. If you run this command 10 times in a row it'll rebuild the same libraries 10 times. Presumably, there are cases (like libpng) when it is desirable to rebuild dependencies but they aren't broken in the way that revdep-rebuild normally can detect. So using --library will brute-force rebuild everything that depends on that library, just to make sure they are built against the new version. Moral of the story; if an ebuild tells you to revdep-rebuild --library, do it. :)
Re: [gentoo-user] Re: Updating libpng: another lib tool cockup?
Allan Gottlieb gottl...@nyu.edu wrote: On Mon, Sep 19 2011, Michael Schreckenbauer wrote: On Monday, 19. September 2011 10:20:25 Allan Gottlieb wrote: On Mon, Sep 19 2011, Alan McKinnon wrote: revdep-rebuild checks everything, revdep-rebuild --library checks just some things. ebuilds sometimes issue messages to check just the libraries known to have been updated, but a full revdep-rebuild after an update will catch those anyway. Until recently I skipped the --library step exactly because I knew revdep-rebuild will find and fix the broken packages after I delete the old library. So, why bother with the --library step, right? However. A few weeks ago I got caught when I deleted one of those obsolete libraries and only then did I find out that gcc is one of the packages that depend on it :( I don't skip the --library step any more. That's odd behaviour, I wonder what caused the difference. Surely revdep-rebuild itself can't do this different just because you specified a library to compare? I wonder if that lib was maybe in the revdep-rebuild exclude list. I'd be interested to track it down for reference, do you remember the library involved? It occurs exactly in the case we are discussing libpng ajglap gottlieb # revdep-rebuild; revdep-rebuild --library '/usr/lib64/libpng14.so.14' * Configuring search environment for revdep-rebuild * Checking reverse dependencies * Packages containing binaries and libraries broken by a package update * will be emerged. ... * Checking reverse dependencies * Packages containing binaries and libraries using /usr/lib64/libpng14.so.14 * will be emerged. First one emerges *broken* packages. Second one emerge packages *using* png14 (not necessarily broken) OK. But the claim was that: if revdep-rebuild with no argument found nothing to build, then revdep-rebuild --library some-library will find nothing. This guarantee is apparently no long true as my example in another msg illustrated. Will emerge @preserved-rebuild catch the second case here? -- Your life is like a penny. You're going to lose it. The question is: How do you spend it? John Covici cov...@ccs.covici.com
Re: [gentoo-user] Re: Updating libpng: another lib tool cockup?
On Mon, Sep 19 2011, Paul Hartman wrote: On Mon, Sep 19, 2011 at 9:58 AM, Allan Gottlieb gottl...@nyu.edu wrote: OK. But the claim was that: if revdep-rebuild with no argument found nothing to build, then revdep-rebuild --library some-library will find nothing. I think what everyone (except Michael S) seems to be confused about is: Normal revdep-rebuild (with no options) looks for broken shared library dependencies and rebuilds them. If you run it again, it won't rebuild anything, because the dependency has been fixed. Using the --library switch, however, it looks for everything built against that library, regardless of whether or not the dependency is broken, and rebuilds it. If you run this command 10 times in a row it'll rebuild the same libraries 10 times. Presumably, there are cases (like libpng) when it is desirable to rebuild dependencies but they aren't broken in the way that revdep-rebuild normally can detect. So using --library will brute-force rebuild everything that depends on that library, just to make sure they are built against the new version. Moral of the story; if an ebuild tells you to revdep-rebuild --library, do it. :) Thanks for the clarification. When revdep-rebuild --library is suggested should we run it before or after the ordinary revdep-rebuild that we typically run after each update world? (That was actually my original question :-) thanks, allan
Re: [gentoo-user] Re: Updating libpng: another lib tool cockup?
On Mon, Sep 19, 2011 at 12:57 PM, Allan Gottlieb gottl...@nyu.edu wrote: When revdep-rebuild --library is suggested should we run it before or after the ordinary revdep-rebuild that we typically run after each update world? I think you should run it with --library first. There exists the possiblity that --library will rebuild something that a normal revdep-rebuild would have also wanted to rebuild, so running --library first could potentially save you from repeat rebuilding.
Re: [gentoo-user] Re: Updating libpng: another lib tool cockup?
On Mon, Sep 19 2011, Paul Hartman wrote: On Mon, Sep 19, 2011 at 12:57 PM, Allan Gottlieb gottl...@nyu.edu wrote: When revdep-rebuild --library is suggested should we run it before or after the ordinary revdep-rebuild that we typically run after each update world? I think you should run it with --library first. There exists the possiblity that --library will rebuild something that a normal revdep-rebuild would have also wanted to rebuild, so running --library first could potentially save you from repeat rebuilding. thanks, allan
