| Summary: | sys-apps/portage preserved-libs thinks libjpeg.so.62.0.0 is required, while SONAME is libjpeg.so.62 | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | SpanKY <vapier> |
| Component: | [OLD] Library | Assignee: | Portage team <dev-portage> |
| Status: | RESOLVED DUPLICATE | ||
| Severity: | normal | CC: | esigra, hyedad, ssuominen |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | |||
| Bug Blocks: | 240323 | ||
| Attachments: |
Patch to only install libjpeg.so.62 and a symlink to libjpeg.so.62.0.0
Remove libjpeg.so.62.0.0 installation. |
||
|
Description
SpanKY
2009-09-14 15:17:45 UTC
Created attachment 204135 [details, diff]
Patch to only install libjpeg.so.62 and a symlink to libjpeg.so.62.0.0
... in case libjpeg.so.62.0.0 is useful.
the symlink is a waste of space whether it's a file or symlink After removing so.62.0.0 from the package to install only the SONAME version I get:
!!! existing preserved libs:
>>> package: media-libs/jpeg-compat-6b
* - /usr/lib64/libjpeg.so.62.0.0
* used by /opt/icedtea6-bin-1.4.1/jre/lib/amd64/libsplashscreen.so (dev-java/icedtea6-bin-1.4.1)
* used by /opt/savage2/libk2.so (games-strategy/savage2-bin-2.1.0)
And "rebuilding" as in reinstalling these pkgs won't help.
$ objdump -p /usr/lib64/libjpeg.so.62 | grep SONAME SONAME libjpeg.so.62 $ objdump -p /opt/icedtea6-bin-1.4.1/jre/lib/amd64/libsplashscreen.so | grep libjpeg NEEDED libjpeg.so.62 Looks like a bug in preserved-libs? check the NEEDED.ELF file of icetea to see what portage recorded at the time of install (In reply to comment #6) > check the NEEDED.ELF file of icetea to see what portage recorded at the time of > install > X86_64;/opt/icedtea6-bin-1.4.1/jre/lib/amd64/libsplashscreen.so;libsplashscreen.so;$ORIGIN;libX11.so.6,libXext.so.6,libm.so.6,libpng12.so.0,libjpeg.so.62,libgif.so.4,libz.so.1,libpthread.so.0,libc.so.6 Right, then I have to look into the code for the exact details. Thing is, portage tries to group the objects, but I thought it only did that on symlinks. It might be the case it just blindly assumes that if the basename is the same, it will be pointing to the same lib, without checking for symlinks. That could cause this problem. Created attachment 204181 [details, diff]
Remove libjpeg.so.62.0.0 installation.
I agree that only SONAME version is required but because this jpeg transition is confusing as it is for users I suggest we wait until preserved-libs is fixed before committing.
Comment on attachment 204181 [details, diff]
Remove libjpeg.so.62.0.0 installation.
yes, this is the patch to go with ultimately
wonder if pkg_preinst() could be used to manually remove the library and avoid the issue ...
(In reply to comment #10) > wonder if pkg_preinst() could be used to manually remove the library and avoid > the issue ... looks like it... committed. moving the bug to dev-portage@ in case they want to improve the preserved-libs behavior in future. See Comments from #3 to #8. Is it correct that libjpeg.so.62.0.0 is the real file with libjpeg.so.62 being a symlink to it? On Darwin this seems to be the case, making Portage look like it's doing the right thing.
167940 2008-02-02 16:13 /Library/Gentoo/usr/lib/libjpeg.62.0.0.dylib
20 2008-02-02 16:13 /Library/Gentoo/usr/lib/libjpeg.62.dylib -> libjpeg.62.0.0.dylib
% scanmacho --soname /Library/Gentoo/usr/lib/libjpeg.62.0.0.dylib
ARCH TYPE INSTALLNAME FILE
ppc MH_DYLIB /Library/Gentoo/usr/lib/libjpeg.62.dylib /Library/Gentoo/usr/lib/libjpeg.62.0.0.dylib
if libjpeg.so.62 is a symlink to libjpeg.so.62.0.0, then there is no bug. but in this case, it is no longer a symlink. libjpeg.so.62 is a real file and libjpeg.so.62.0.0 is removed from the system. but portage tries to keep it around. Ok, to remove some confusion, media-libs/jpeg just creates the symlink libjpeg.so.62 -> libjpeg.so.62.0.0, which means portage preserving it (as it does on my systems) is correct. I don't have jpeg-compat installed. jpeg-compat is different most probably because of the doexe which transforms symlinks into real files, as used in the ebuild's src_install. Conclusion, libjpeg.so.62.0.0 is a useless file in jpeg-compat (nothing new so far). However, it has the same soname as libjpeg.so.62, so I suspect now that Portage sees both files as provider for the same lib (libjpeg.so.62), and it has no good way to see which one can go. So, my first conclusion here would be that jpeg-compat introduced the problem more or less itself, and that it now fixes the problem itself too. Great. Portage could in this case do some "magic" to remove the real lib with soname that doesn't match its own file name, since other real providers exist that do have a filename which matches the soname. At first sight this is not trivial though. Just as sidenote, removing duplicate providers is not a good idea either, as some -- binary packages for instance -- may install libs which already exist but in e.g. /opt/bla/lib/X and Portage should not unmerge those just because their soname is equal to the /usr/lib/X one. >>> Regenerating /etc/ld.so.cache...
/sbin/ldconfig: /usr/lib/libjpeg.so.62 is not a symbolic link
that issue is already resolved and doesnt need looking into (In reply to comment #14) > Ok, to remove some confusion, media-libs/jpeg just creates the symlink > libjpeg.so.62 -> libjpeg.so.62.0.0, which means portage preserving it (as it > does on my systems) is correct. I don't have jpeg-compat installed. > > jpeg-compat is different most probably because of the doexe which transforms > symlinks into real files, as used in the ebuild's src_install. Conclusion, > libjpeg.so.62.0.0 is a useless file in jpeg-compat (nothing new so far). > However, it has the same soname as libjpeg.so.62, so I suspect now that Portage > sees both files as provider for the same lib (libjpeg.so.62), and it has no > good way to see which one can go. What you described about having same SONAME and Portage not knowing which version should go, isn't that same as in bug 289180? In that case, both gcc and external libffi provided libraries with same SONAME too, and Portage didn't remove the gcc's version of it. If that's the case, perhaps this should just be duped there, afterall, what's the point of having 2 bugs for the same issue? (In reply to comment #17) > If that's the case, perhaps this should just be duped there, afterall, what's > the point of having 2 bugs for the same issue? Okay, done. *** This bug has been marked as a duplicate of bug 289180 *** |