revdep-rebuild --soname libcrypto.so.0.9.6 wants to rebuild openssl. This is looks like because libssl.so.0.9.6 depends on libcrypto.so.0.9.6 but rebuilding openssl is pointless since I had just rebuilt it, prompting me to do the revdep-rebuild in the first place. Should probably do a check for this kind of circular behavior. Reproducible: Always Steps to Reproduce: 1. emerge openssl-0.9.7c 2. revdep-rebuild --soname libcrypto.so.0.9.6 Actual Results: It starts rebuilding openssl-0.9.7c Expected Results: Ignore openssl.
Just to also note that "revdep-rebuild --soname libcrypto.so.0.9.6" will always see that libssl.so.0.9.6 then until the file is manually deleted.
Hmm, this is a problem, because generally you don't know, that linking against this library is delibrate (as for openssl) or mistake (as for some versions of GIMP, where just compiled plug-ins were linked against old version of library). For example some And generally, it is not a good idea, that some package provides two incompatible libraries - I have got warning messages from linker, because half of libraries was linked against libcrypto.so.0.9.6 and second half against libcrypto.so.0.9.7. If the library contains static strings, it can be allocated twice and some calls use one instance, other second one. I know, for openssl it's nearly must. But I haven't any idea, how to discriminate, that it's OK for libssl.so.0.9.6 to be linked against libcrypto.so.0.9.6, but it's not OK for, say libssl.so.0.9.7 (for correctly written packages it cannot occur, but there are many packages with this bug).
Any ideas here? Still an issue w/ openssl-0.9.8c
Unfortunately, I don't have any ideas. However, I still have some boxes that need openssl updated and will play with it then to see if I can come up with anything.
*** Bug 210383 has been marked as a duplicate of this bug. ***
I am author of bug 210383 closed above. Will dev-libs/nspr-4.7 require a fix ? or will the fix lay in revdep ?
(In reply to comment #6) There's nothing to fix in the ebuilds; revdep-rebuild should drop the owner of the file passed to it via --library from the list of stuff to be rebuilt.
(In reply to comment #7) > (In reply to comment #6) > > There's nothing to fix in the ebuilds; revdep-rebuild should drop the owner of > the file passed to it via --library from the list of stuff to be rebuilt. That's easily done if the user passes a fully-qualified path-to-soname to --library. What should we do if he uses a pattern like libcr.*\.so.*? If we dropped the pattern-matching logic it would be much easier to fix this bug. (Frankly, I'm of the opinion that the soname-regex pattern matching logic is not worth keeping -- it's a pain to maintain and I don't believe it's used all that often.) We could allow lists of sonames without allowing actual regex. Thoughts?
If you have a fully-qualified path as suggested in comment #8 then you can use the `portageq owners` command to find the owner. That command does inode comparison if necessary to ensure that it works even if the path you give it isn't exactly the same as the one listed in the contents (due to symlinks). There's also a `portageq contents` command that you can use to get a full contents listing for a package but it would be kind of slow to call that for each installed package until you find a match.
Created attachment 144587 [details, diff] revdep-rebuild_skip-rebuild-libowner.patch With this patch r-r greps the full path of the library from the output of ldd. Then it tries to find the owner of that lib. If it finds a match it adds the package to an exclude list and won't rebuild that package unless the (new) -O/--merge-owner flag is used. Please test. (There is one known bug with it, if the --library pattern matches more than one line of ldd's output only the first line will be used. Most of the time that shouldn't be a big deal, but it could cause some owners to still get rebuilt. I have a plan to fix it...)
So, anyone looking at this? Still there, just hit it w/ dev-libs/icu
I'll look at it for inclusion in the the gentoolkit-0.3.0 series. To be honest, this hasn't been a high priority since it is more of an annoyance than anything. Regarding icu, that one looked legitimate since the package failed to install libicutest.so.44 required by /usr/bin/icuinfo
Let's see if we can fix this in 0.3.1
(In reply to comment #10) > Created attachment 144587 [details, diff] [details, diff] > revdep-rebuild_skip-rebuild-libowner.patch > > With this patch r-r greps the full path of the library from the output of > ldd. Then it tries to find the owner of that lib. If it finds a match it > adds the package to an exclude list and won't rebuild that package unless > the (new) -O/--merge-owner flag is used. > > Please test. > > (There is one known bug with it, if the --library pattern matches more than > one line of ldd's output only the first line will be used. Most of the time > that shouldn't be a big deal, but it could cause some owners to still get > rebuilt. I have a plan to fix it...) Any news on this? I hit this on every opensp update Thanks!
Ping. Is this still a problem? The listed versions in this bug are no longer in the Portage tree.
Yes, this is still an issue. If you run revdep-rebuild --library libcrypto.so.1.0.0 --pretend, you will see openssl in the list of packages to be rebuilt.