Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bugzilla DB migration completed. Please report issues to Infra team via email via infra@gentoo.org or IRC
Bug 284944 - sys-apps/portage preserved-libs thinks libjpeg.so.62.0.0 is required, while SONAME is libjpeg.so.62
Summary: sys-apps/portage preserved-libs thinks libjpeg.so.62.0.0 is required, while S...
Status: RESOLVED DUPLICATE of bug 289180
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] Library (show other bugs)
Hardware: All Linux
: High normal (vote)
Assignee: Portage team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: preserve-libs
  Show dependency tree
 
Reported: 2009-09-14 15:17 UTC by SpanKY
Modified: 2011-07-16 18:16 UTC (History)
3 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
Patch to only install libjpeg.so.62 and a symlink to libjpeg.so.62.0.0 (jpeg-compat-6b-install.patch,380 bytes, patch)
2009-09-14 21:38 UTC, Gef
Details | Diff
Remove libjpeg.so.62.0.0 installation. (jpeg-compat-6b.ebuild.patch,547 bytes, patch)
2009-09-15 12:32 UTC, Samuli Suominen
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description SpanKY gentoo-dev 2009-09-14 15:17:45 UTC
media-libs/jpeg-compat installs both a libjpeg.so.62 and a libjpeg.so.62.0.0.  only the former (SONAME) is required.  the latter is simply a waste of space.
Comment 1 Gef 2009-09-14 21:38:44 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.
Comment 2 SpanKY gentoo-dev 2009-09-14 21:47:53 UTC
the symlink is a waste of space whether it's a file or symlink
Comment 3 Samuli Suominen gentoo-dev 2009-09-15 08:03:13 UTC
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.
Comment 4 Samuli Suominen gentoo-dev 2009-09-15 08:05:07 UTC
$ 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
Comment 5 Samuli Suominen gentoo-dev 2009-09-15 08:05:42 UTC
Looks like a bug in preserved-libs?
Comment 6 Fabian Groffen gentoo-dev 2009-09-15 08:16:49 UTC
check the NEEDED.ELF file of icetea to see what portage recorded at the time of install
Comment 7 Samuli Suominen gentoo-dev 2009-09-15 08:22:35 UTC
(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
Comment 8 Fabian Groffen gentoo-dev 2009-09-15 08:29:41 UTC
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.
Comment 9 Samuli Suominen gentoo-dev 2009-09-15 12:32:59 UTC
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 10 SpanKY gentoo-dev 2009-09-15 16:19:03 UTC
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 ...
Comment 11 Samuli Suominen gentoo-dev 2009-09-15 17:03:23 UTC
(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.
Comment 12 Fabian Groffen gentoo-dev 2009-09-16 18:25:50 UTC
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 
Comment 13 SpanKY gentoo-dev 2009-09-16 18:59:44 UTC
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.
Comment 14 Fabian Groffen gentoo-dev 2009-10-03 10:42:41 UTC
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.
Comment 15 Mikael Magnusson 2009-10-26 19:41:21 UTC
>>> Regenerating /etc/ld.so.cache...
/sbin/ldconfig: /usr/lib/libjpeg.so.62 is not a symbolic link
Comment 16 SpanKY gentoo-dev 2009-10-26 20:56:25 UTC
that issue is already resolved and doesnt need looking into
Comment 17 Samuli Suominen gentoo-dev 2010-02-23 18:47:46 UTC
(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?
Comment 18 Zac Medico gentoo-dev 2011-07-16 18:16:55 UTC
(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 ***