| Summary: | portage-2.2_rc12 @perserved-rebuild function appears possible to confuse re: libkipi | ||
|---|---|---|---|
| Product: | Portage Development | Reporter: | Guy <defuebr> |
| Component: | Core - Ebuild Support | Assignee: | Portage team <dev-portage> |
| Status: | RESOLVED INVALID | ||
| Severity: | normal | CC: | esigra |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | |||
| Bug Blocks: | 240323 | ||
|
Description
Guy
2008-10-27 13:39:38 UTC
(In reply to comment #0) > I'm guessing this is a special case where I have kde-3.5.10, kde-4.1.2 and > kphotoalbum (which resides in media-qfx) and each is using different libkipi > libraries. I haven't studied this problem in detail, but my first guess it that it's something more like bug 230257. In some cases, rebuilding a package doesn't seem to solve the problem because the build system incorrectly links against the preserved library instead of the new one. As a workaround for cases like this, you can remove the library by hand (temporarily breaking the packages that depend on it) and then use revdep-rebuild to rebuild the broken packages. Please report back if this solves the problem. So, if I understand you correctly, I should:
rm -f /usr/lib64/libkipi*
rm -f /usr/kde/3.5/lib64/libkipi*
Then run "revdep-rebuild".
Yes?
In the meantime, out of curiosity, I ran "revdep-rebuild -p". These were the results:
# revdep-rebuild -p
* Configuring search environment for revdep-rebuild
* Checking reverse dependencies
* Packages containing binaries and libraries broken by a package update
* will be emerged.
* Collecting system binaries and libraries
* Generated new 1_files.rr
* Collecting complete LD_LIBRARY_PATH
* Generated new 2_ldpath.rr
* Checking dynamic linking consistency
[ 35% ] * broken /usr/lib/gcc/x86_64-pc-linux-gnu/4.2.4/libgij.la (requires /usr/lib/../lib64/libgcj.la)
[ 48% ] * broken /usr/lib64/gcc/x86_64-pc-linux-gnu/4.2.4/libgij.la (requires /usr/lib/../lib64/libgcj.la)
* broken /usr/lib64/gcj-4.2.4/libjvm.la (requires /usr/lib/../lib64/libgcj.la)
[ 62% ] * broken /usr/lib64/libSDL.la (requires /usr/lib64/libcucul.la)
* broken /usr/lib64/libSDL_image.la (requires /usr/lib64/libcucul.la)
* broken /usr/lib64/libSDL_ttf.la (requires /usr/lib64/libcucul.la)
[ 70% ] * broken /usr/lib64/liblavplay.la (requires /usr/lib64/libcucul.la)
[ 79% ] * broken /usr/lib64/mpg123/output_sdl.la (requires /usr/lib64/libcucul.la)
[ 90% ] * broken /usr/lib64/transcode/filter_preview.la (requires /usr/lib64/libcucul.la)
* broken /usr/lib64/transcode/filter_pv.la (requires /usr/lib64/libcucul.la)
[ 92% ] * broken /usr/lib64/vlc/audio_output/libaout_sdl_plugin.la (requires /usr/lib64/libcucul.la)
* broken /usr/lib64/vlc/codec/libsdl_image_plugin.la (requires /usr/lib64/libcucul.la)
[ 94% ] * broken /usr/lib64/vlc/video_output/libcaca_plugin.la (requires /usr/lib64/libcucul.la)
* broken /usr/lib64/vlc/video_output/libvout_sdl_plugin.la (requires /usr/lib64/libcucul.la)
[ 100% ]
* Generated new 3_broken.rr
* Assigning files to packages
* /usr/lib/gcc/x86_64-pc-linux-gnu/4.2.4/libgij.la -> sys-devel/gcc
* !!! /usr/lib64/gcc/x86_64-pc-linux-gnu/4.2.4/libgij.la not owned by any package is broken !!!
* /usr/lib64/gcc/x86_64-pc-linux-gnu/4.2.4/libgij.la -> (none)
* /usr/lib64/gcj-4.2.4/libjvm.la -> sys-devel/gcc
* /usr/lib64/libSDL.la -> media-libs/libsdl
* /usr/lib64/libSDL_image.la -> media-libs/sdl-image
* /usr/lib64/libSDL_ttf.la -> media-libs/sdl-ttf
* /usr/lib64/liblavplay.la -> media-video/mjpegtools
* /usr/lib64/mpg123/output_sdl.la -> media-sound/mpg123
* /usr/lib64/transcode/filter_preview.la -> media-video/transcode
* /usr/lib64/transcode/filter_pv.la -> media-video/transcode
* /usr/lib64/vlc/audio_output/libaout_sdl_plugin.la -> media-video/vlc
* /usr/lib64/vlc/codec/libsdl_image_plugin.la -> media-video/vlc
* /usr/lib64/vlc/video_output/libcaca_plugin.la -> media-video/vlc
* /usr/lib64/vlc/video_output/libvout_sdl_plugin.la -> media-video/vlc
* Generated new 4_raw.rr and 4_owners.rr
* Cleaning list of packages to rebuild
* Generated new 4_pkgs.rr
* Assigning packages to ebuilds
* Generated new 4_ebuilds.rr
* Evaluating package order
* Generated new 5_order.rr
* All prepared. Starting rebuild
emerge --oneshot --pretend media-libs/libsdl:0
media-libs/sdl-image:0
media-libs/sdl-ttf:0
media-sound/mpg123:0
media-video/mjpegtools:1
media-video/transcode:0
media-video/vlc:0
sys-devel/gcc:4.2
These are the packages that would be merged, in order:
Calculating dependencies... done!
[ebuild R ] media-libs/libsdl-1.2.13
[ebuild R ] sys-devel/gcc-4.2.4
[ebuild R ] media-libs/sdl-image-1.2.6-r1
[ebuild R ] media-video/mjpegtools-1.9.0_rc3
[ebuild R ] media-libs/sdl-ttf-2.0.9
[ebuild R ] media-sound/mpg123-1.5.1
[ebuild R ] media-video/transcode-1.0.7_rc1
[ebuild R ] media-video/vlc-0.9.5
!!! existing preserved libs:
>>> package: media-libs/libkipi-0.1.6-r1
* - /usr/lib64/libkipi.so.0
* - /usr/lib64/libkipi.so.0.1.1
* used by /usr/bin/kphotoalbum (media-gfx/kphotoalbum-3.1.1-r1)
* used by /usr/lib64/kde3/kipiplugin_acquireimages.so (media-plugins/kipi-plugins-0.1.5)
* used by /usr/lib64/kde3/kipiplugin_batchprocessimages.so (media-plugins/kipi-plugins-0.1.5)
* used by 20 other files
Use emerge @preserved-rebuild to rebuild packages using these libraries
* Now you can remove -p (or --pretend) from arguments and re-run revdep-rebuild.
I had interpreted the documentation regarding that the new portage "sets" functionality combined with "@preserved-rebuild" could perhaps greatly reduce or even eliminate the need for revdep-rebuild {as a general thing} so I haven't been vigilant about running it. {an aside - this is NOT any criticism!! - I very much like what I see with the new portage functionality!}
In the interests of giving you as much information as possible, I'm running revdep-rebuild now and will try "emerge @preserved-rebuild" immediately after.
Then I will delete the "libkipi" files as above and re-run "revdep-rebuild" again. If you could comment before I reach this point, it would be appreciated.
(In reply to comment #2) > So, if I understand you correctly, I should: > > rm -f /usr/lib64/libkipi* > rm -f /usr/kde/3.5/lib64/libkipi* > > Then run "revdep-rebuild". > > Yes? No, not exactly. You should only remove the libraries that have actually been preserved. They are listed in the "!!! existing preserved libs" message shown in comment #0: > !!! existing preserved libs: > >>> package: media-libs/libkipi-0.1.6-r1 > * - /usr/lib64/libkipi.so.0 > * - /usr/lib64/libkipi.so.0.1.1 (In reply to comment #2) > I had interpreted the documentation regarding that the new portage "sets" > functionality combined with "@preserved-rebuild" could perhaps greatly reduce > or even eliminate the need for revdep-rebuild {as a general thing} so I haven't You are probably thinking of as-needed, which is what will greatly reduce the number of rebuilds that are necessary: http://www.gentoo.org/proj/en/qa/asneeded.xml > been vigilant about running it. {an aside - this is NOT any criticism!! - I > very much like what I see with the new portage functionality!} The functionality that is provided by @preserved-rebuild serves as a replacement for part of the functionality that used to be provided by revdep-rebuild. However, since we are trying to work around a buggy build system here, we have to use revdep-rebuild instead of @preserved-rebuild. Thank you for the clarification and comments. This is what I did: slizard ~ # ls -l /usr/lib64/libkipi.so.0* lrwxrwxrwx 1 root root 16 Oct 15 21:52 /usr/lib64/libkipi.so.0 -> libkipi.so.0.1.1 -rwxr-xr-x 1 root root 263600 Dec 25 2007 /usr/lib64/libkipi.so.0.1.1 slizard ~ # rm /usr/lib64/libkipi.so.0* slizard ~ # ls -l /usr/lib64/libkipi.so.0* ls: cannot access /usr/lib64/libkipi.so.0*: No such file or directory revdep-rebuild is running again now. revdep-rebuild finished. There are no more @preserved-rebuild items left. Thank you. So, this bug seems similar to bug 231563 in the sense that dev-util/pkgconfig doesn't seem to be generating the correct compile/link flags when the old lib has been preserved. (In reply to comment #7) > So, this bug seems similar to bug 231563 in the sense that dev-util/pkgconfig > doesn't seem to be generating the correct compile/link flags when the old lib > has been preserved. Actually, it seems to be a problem with libtool as mentioned in bug #231563, comment #17. I'm the originally reporter and I'm closing this because I've observed no further instances of this happening. I suspect that circumstances for this to happen require improper artifacts left from possible previously broken ebuilds. In other words, on a properly built recent vintage system, this problem most likely will never happen. |
