| Summary: | emerge asks to do "emerge @preserved-rebuild" but doing so doesn't fix anything | ||
|---|---|---|---|
| Product: | Portage Development | Reporter: | headcrabextra |
| Component: | Unclassified | Assignee: | Julian Ospald <hasufell> |
| Status: | RESOLVED OBSOLETE | ||
| Severity: | normal | CC: | dolsen, mgorny |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | AMD64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: |
NEEDED
NEEDED.ELF.2 |
||
|
Description
headcrabextra
2014-02-17 04:09:00 UTC
big_daddy portage # e-file /usr/lib32/libfribidi.so.0 [I] app-emulation/emul-linux-x86-medialibs Available Versions: 20130224-r7 20110722 20130224-r8 20110129 20130224-r6 20100915-r1 20130224-r5 20100915 20130224-r4 20100611-r0 20130224-r2 20100220 20130224-r1 20100611 20130224 20131008 20100409 20131008-r1 20100409-r0 20121202 20130224-r13 20100220-r0 20130224-r12 20091231-r0 20121028 20120520 20130224-r11 20120127 20130224-r9 20110928 Last Installed Ver: 20130224-r2(Thu 18 Jul 2013 01:37:00 AM PDT) Matched Files: /usr/lib32/libfribidi.so.0; [I] dev-libs/fribidi Available Versions: 0.19.5-r1 0.19.5 0.19.5-r2 Last Installed Ver: 0.19.5-r2(Wed 15 Jan 2014 11:42:34 AM PST) Matched Files: /usr/lib32/libfribidi.so.0; big_daddy portage # So, there are 2 pkgs that supply that lib. It is very likely that games-misc/katawa-shoujo-1.1 directly links to the existing lib it finds in your system. Try adding --with-bdeps=y to a re-emerge of games-misc/katawa-shoujo-1.1. That should bring back in the dep supplying that lib. Alternatively you may have to delete that lib, then re-emerge the game. hmm, looks like the ebuild doesn't list that dependency. Julian. Looks like this ame is missing a dependency, causing the pkg to not re-install the depcleaned pkg supplying the preserved lib. (In reply to Brian Dolbec from comment #2) > hmm, looks like the ebuild doesn't list that dependency. > > Julian. Looks like this ame is missing a dependency, causing the pkg to not > re-install the depcleaned pkg supplying the preserved lib. # ls /opt/katawa-shoujo/lib/linux-x86/lib libavcodec.so.52 libfribidi.so.0 libSDL_image-1.2.so.0 python2.5 libavformat.so.52 libpng.so.3 libSDL_ttf-2.0.so.0 libavutil.so.49 libpython2.5.so.1.0 libsmpeg-0.4.so.0 libfreetype.so.6 libSDL-1.2.so.0 libXau.so.6 Looks like the game is bundling it's own copy. hmm, I wonder if it is a case of a mistaken path or it is actually linking to the preserved lib rather than the bundled lib. Can you please attach a copy of both the NEEDED and NEEDED.ELF.2 files. They should be located in /var/db/pkg/games-misc/katawa-shoujo-1.1/ Created attachment 370644 [details]
NEEDED
Created attachment 370646 [details]
NEEDED.ELF.2
Julian, it looks like everything is linking to system libs, not the bundled ones.
I emerged it and run some tests. Also my NEEDED and NEEDED.ELF.2 seem to match, at least for a few libs I checked.
big_daddy portage # ls -l /usr/lib32/libSDL-1.2.so.0
lrwxrwxrwx 1 root root 20 Jul 18 2013 /usr/lib32/libSDL-1.2.so.0 -> libSDL-1.2.so.0.11.4
big_daddy portage # ldd /opt/katawa-shoujo/lib/linux-x86/lib/libSDL_ttf-2.0.so.0
ldd: warning: you do not have execution permission for `/opt/katawa-shoujo/lib/linux-x86/lib/libSDL_ttf-2.0.so.0'
linux-gate.so.1 (0xf779c000)
libfreetype.so.6 => /usr/lib32/libfreetype.so.6 (0xf76b3000)
libz.so.1 => /lib32/libz.so.1 (0xf769c000)
libSDL-1.2.so.0 => /usr/lib32/libSDL-1.2.so.0 (0xf763f000)
libpthread.so.0 => /lib32/libpthread.so.0 (0xf7623000)
...
The matching line in NEEDED.ELF.2:
386;/opt/katawa-shoujo/lib/linux-x86/lib/libSDL_ttf-2.0.so.0;libSDL_ttf-2.0.so.0;/home/tom/ab/dapper-deps/install/lib;libfreetype.so.6,libz.so.1,libSDL-1.2.so.0,libpthread.so.0,libc.so.6
I confirmed this with other libs as well. You can run ldd for all files reported in the original post to confirm.
Looking through the sources, I found a file in the source that changes the LD_LIBRARY_PATH. Portage has no way of knowing this at install time. So it records the links pointing to the system libs.
headcrabextra, it looks like you will have to delete the preserved libs manually. It might be safer to move them somewhere out of ldd's path, like in a home dir. Just in case you have to restore it. I don't think you will have to re-install.
(In reply to Brian Dolbec from comment #7) > Julian, it looks like everything is linking to system libs, not the bundled > ones. > > I emerged it and run some tests. Also my NEEDED and NEEDED.ELF.2 seem to > match, at least for a few libs I checked. > > big_daddy portage # ls -l /usr/lib32/libSDL-1.2.so.0 > lrwxrwxrwx 1 root root 20 Jul 18 2013 /usr/lib32/libSDL-1.2.so.0 -> > libSDL-1.2.so.0.11.4 > big_daddy portage # ldd > /opt/katawa-shoujo/lib/linux-x86/lib/libSDL_ttf-2.0.so.0 > ldd: warning: you do not have execution permission for > `/opt/katawa-shoujo/lib/linux-x86/lib/libSDL_ttf-2.0.so.0' > linux-gate.so.1 (0xf779c000) > libfreetype.so.6 => /usr/lib32/libfreetype.so.6 (0xf76b3000) > libz.so.1 => /lib32/libz.so.1 (0xf769c000) > libSDL-1.2.so.0 => /usr/lib32/libSDL-1.2.so.0 (0xf763f000) > libpthread.so.0 => /lib32/libpthread.so.0 (0xf7623000) > ... > > The matching line in NEEDED.ELF.2: > > 386;/opt/katawa-shoujo/lib/linux-x86/lib/libSDL_ttf-2.0.so.0;libSDL_ttf-2.0. > so.0;/home/tom/ab/dapper-deps/install/lib;libfreetype.so.6,libz.so.1,libSDL- > 1.2.so.0,libpthread.so.0,libc.so.6 > > I confirmed this with other libs as well. You can run ldd for all files > reported in the original post to confirm. > > Looking through the sources, I found a file in the source that changes the > LD_LIBRARY_PATH. Portage has no way of knowing this at install time. So it > records the links pointing to the system libs. > > headcrabextra, it looks like you will have to delete the preserved libs > manually. It might be safer to move them somewhere out of ldd's path, like > in a home dir. Just in case you have to restore it. I don't think you will > have to re-install. I don't understand how this is a bug in the ebuild. The libraries are bundled, nothing is compiled. (In reply to Julian Ospald (hasufell) from comment #8) > I don't understand how this is a bug in the ebuild. The libraries are > bundled, nothing is compiled. It isn't directly. What seems to be happening is portage is detecting the links to the system libs, not knowing that the game sets the ldd path to point to it's bundled libs. So, @preseved-rebuild is falsely saving the system libs, reporting them as being needed for the game. I will have to check out more about @preserved-rebuild to see if there is a way to set it to not record bundled libs like these as system libs. Perhaps the ebuild may have to set a variable of the bundled libs. That way it won't record them as system libs. Julian, apparently there is a way to fix the libs so it doesn't screw up the preserved-libs feature. The solution is in one of your ebuilds that you inherited. sci-geosciences/googleearth does this. see bug 265372 comment #17 for the solution. It is changes in the ebuild. The ebuild has to run patchelf to set the path correctly. Sorry to play ping pong with the assignment like this. But the ball is in your court again. (In reply to Brian Dolbec from comment #10) > Julian, apparently there is a way to fix the libs so it doesn't screw up the > preserved-libs feature. The solution is in one of your ebuilds that you > inherited. sci-geosciences/googleearth does this. > > see bug 265372 comment #17210 for the solution. > > It is changes in the ebuild. The ebuild has to run patchelf to set the path > correctly. > > Sorry to play ping pong with the assignment like this. But the ball is in > your court again. That has to be done for all bundled libs that are also available as system version? That's a lot. can we fix this on eclass or pm level somehow? for example... QA_PREBUILT could be used to apply something automatically, no? Sorry, I do/know little on the bash side of things. I'm a python coder. You have far more ebuild/eclass knowledge than I do. @mgorny ...what do you think about using QA_PREBUILT for this? (In reply to Julian Ospald (hasufell) from comment #15) > @mgorny ...what do you think about using QA_PREBUILT for this? I'm afraid I don't understand how that would help. Could you elaborate a bit on what exactly would the magic do? (In reply to Brian Dolbec from comment #9) > Perhaps the ebuild may have to set a variable of the bundled libs. That way > it won't record them as system libs. These should be already in QA_PREBUILT. If anyone has a patch for supporting this undocumented feature in one of my packages, open a specific bug... however, I don't intend to actively support or test it. Afais, it should be fixed for katawa-shoujo anyway. |
