When I check the consistency with revdep-rebuild, it always finish with the message: Dynamic linking on your system is consistent... All done. Even if the checking phase shows several broken linkings (and all files are emerged with portage. Reproducible: Always Steps to Reproduce: 1.start revdep-rebuild 2. 3. Actual Results: Here an example of a current run: revdep-rebuild -vv -p Configuring search environment for revdep-rebuild revdep-rebuild environment: SEARCH_DIRS="/usr/qt/3/ /bin/ /sbin/ /usr/bin/ /usr/sbin/ /lib/ /usr/lib/ /usr/libexec/ /opt/bin/ /usr/i686-pc-linux-gnu/gcc-bin/4.1.2/ /opt/ICAClient/ /opt/sun-jdk-1.4.2.14/bin/ /opt/sun-jdk-1.4.2.14/jre/bin/ /opt/sun-jdk-1.4.2.14/jre/javaws/ /usr/kde/3.5/sbin/ /usr/kde/3.5/bin/ /usr/qt/3/bin/ /opt/vmware/workstation/bin/ /opt/bin/ /usr/i686-pc-linux-gnu/gcc-bin/4.1.2/ /opt/ICAClient/ /opt/sun-jdk-1.4.2.14/bin/ /opt/sun-jdk-1.4.2.14/jre/bin/ /opt/sun-jdk-1.4.2.14/jre/javaws/ /usr/kde/3.5/bin/ /usr/qt/3/bin/ /usr/games/bin/ /opt/vmware/workstation/bin/ /usr/local/lib/ /usr/lib/opengl/nvidia/lib/ /usr/i686-pc-linux-gnu/lib/ /usr/lib/gcc/i686-pc-linux-gnu/4.1.2/ /usr/lib/gcc/i686-pc-linux-gnu/4.1.1/ /usr/lib/nspr/ /usr/lib/nss/ /usr/lib/openmotif-2.2/ /opt/sun-jdk-1.4.2.14/jre/lib/i386/ /opt/sun-jdk-1.4.2.14/jre/lib/i386/native_threads/ /opt/sun-jdk-1.4.2.14/jre/lib/i386/classic/ /opt/sun-jdk-1.4.2.14/jre/lib/i386/server/ /usr/lib/qt4/ /usr/kde/3.5/lib/ /usr/qt/3/lib/ /usr/games/lib/ /usr/lib/libstdc++-v3/" SEARCH_DIRS_MASK="/usr/lib/real /usr/lib/win32 /opt/opera/lib/opera/plugins" LD_LIBRARY_MASK="libjvm.so libjawt.so libodbcinst.so libodbc.so libjava.so libjvm.so" PORTAGE_ROOT="/" CALLED_OPTIONS="" EMERGE_OPTIONS="-p" Checking reverse dependencies... Packages containing binaries and libraries broken by a package update will be emerged. Collecting system binaries and libraries... done. (/root/.revdep-rebuild.1_files) Collecting complete LD_LIBRARY_PATH... done. (/root/.revdep-rebuild.2_ldpath) Checking dynamic linking consistency... broken /usr/bin/digikam (requires libexiv2-0.13.so libkexiv2.so.0) broken /usr/bin/gwenview (requires libexiv2-0.13.so) broken /usr/bin/showfoto (requires libexiv2-0.13.so libkexiv2.so.0) broken /usr/lib/kde3/digikamimageplugin_adjustcurves.so (requires libexiv2-0.13.so libk exiv2.so.0) broken /usr/lib/libgwenviewcore.so.1.0.0 (requires libexiv2-0.13.so) broken /usr/lib/libkdeinit_gwenview.so (requires libexiv2-0.13.so) done. (/root/.revdep-rebuild.3_rebuild) Assigning files to ebuilds... done. (/root/.revdep-rebuild.4_ebuilds) Evaluating package order... done. (/root/.revdep-rebuild.5_order) Dynamic linking on your system is consistent... All done. Freya ~ # Expected Results: that the rebuild of the packages are suggested Portage 2.1.2.7 (default-linux/x86/2006.1/desktop, gcc-4.1.2, glibc-2.5-r2, 2.6.20-gentoo-r8 i686) ================================================================= System uname: 2.6.20-gentoo-r8 i686 Intel(R) Pentium(R) 4 CPU 3.20GHz Gentoo Base System release 1.12.9 Timestamp of tree: Tue, 22 May 2007 05:50:01 +0000 distcc 2.18.3 i686-pc-linux-gnu (protocols 1 and 2) (default port 3632) [disabled] ccache version 2.4 [enabled] dev-java/java-config: 1.3.7, 2.0.31-r5 dev-lang/python: 2.4.4-r4 dev-python/pycrypto: 2.0.1-r5 dev-util/ccache: 2.4-r7 sys-apps/sandbox: 1.2.17 sys-devel/autoconf: 2.13, 2.61 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10 sys-devel/binutils: 2.16.1-r3 sys-devel/gcc-config: 1.3.16 sys-devel/libtool: 1.5.22 virtual/os-headers: 2.6.17-r2 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CBUILD="i686-pc-linux-gnu" CFLAGS="-O2 -march=prescott -fomit-frame-pointer -pipe" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/share/X11/xkb /usr/share/config" CONFIG_PROTECT_MASK="/etc/env.d /etc/env.d/java/ /etc/gconf /etc/java-config/vms/ /etc/revdep-rebuild /etc/splash /etc/terminfo /etc/texmf/web2c" CXXFLAGS="-O2 -march=prescott -fomit-frame-pointer -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="ccache distlocks metadata-transfer sandbox sfperms strict" GENTOO_MIRRORS="http://ftp.uni-erlangen.de/pub/mirrors/gentoo http://mirror.uni-c.dk/pub/gentoo/ http://linux.rz.ruhr-uni-bochum.de/download/gentoo-mirror/" LANG="de_DE.utf8" LC_ALL="de_DE.utf8" LINGUAS="de" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --delete-after --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages --filter=H_**/files/digest-*" PORTAGE_TMPDIR="/data/system/var/" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/data/portage" SYNC="rsync://rsync.europe.gentoo.org/gentoo-portage" USE="X a52 aac acpi alsa arts asf audiofile bash-completion berkdb bitmap-fonts bluetooth browserplugin bzip2 cairo capi cdparanoia cdr cli cracklib crypt css cups curl dbus dga directfb dri dts dv dvb dvd dvdr dvdread dvdreadi eds emboss encode esd exif fam fame fax ffmpeg firefox font-server fortran fping gdbm gif gimp gimpprint glut gmp gpm gstreamer gtk gtk2 hal iconv icq idn ieee1394 imagemagick imlib ipod isdnlog java javascript joystick jpeg jpeg2k kde kdeenablefinal kdehiddenvisibility kipi koffice-plugin lcms libg++ lua mad maildir matroska mbox midi mikmod mime mjpeg mmx mmxext mng moneyplex monkey mozbranding moznocompose moznoirc moznomail mozsvg mp3 mpeg mplayer msn mudflap musicbrainz mysql ncurses nls nptl nptlonly nsplugin objc ogg openal opengl openmp oscar oss pam pcre perl png ppds pppd python qt3 qt4 quicktime rar rdesktop readline real reflection reiserfs ruby samba scanner sdl session smp sms sox speedo spell spl sqlite sse sse-filters sse2 ssl stats subtitles sysfs tcltk tcpd theora tiff truetype truetype-fonts type1-fonts unicode usb utf8 v4l vcd videos vidix vorbis win32codecs x86 xcomposite xine xinerama xml xorg xpm xscreensaver xv xvid yahoo zlib" ALSA_CARDS="cs46xx" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mulaw multi null plug rate route share shm softvol" ELIBC="glibc" FRITZCAPI_CARDS="fcpci" INPUT_DEVICES="keyboard joystick mouse" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LINGUAS="de" USERLAND="GNU" VIDEO_CARDS="nvidia" Unset: CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LDFLAGS, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS
I shortened the output of revdep, because the list is so much long with the kipi-plugins.
You will see that behavior when files are orphaned. What do the following equery commands return: equery belongs /usr/bin/digikam equery belongs /usr/bin/gwenview equery belongs /usr/bin/showfoto equery belongs /usr/lib/kde3/digikamimageplugin_adjustcurves.so equery belongs /usr/lib/libgwenviewcore.so.1.0.0 equery belongs /usr/lib/libkdeinit_gwenview.so
Actually, I have to query all files for my own and build the emerge string manually. The equery outputs this here: equery belongs /usr/bin/digikam /usr/bin/gwenview /usr/bin/showfoto /usr/lib/kde3/digikamimageplugin_adjustcurves.so /usr/lib/libgwenviewcore.so.1.0.0 usr/lib/libkdeinit_gwenview.so [ Searching for file(s) /usr/bin/digikam,/usr/bin/gwenview,/usr/bin/showfoto,/usr/lib/kde3/digikamimageplugin_adjustcurves.so,/usr/lib/libgwenviewcore.so.1.0.0,usr/lib/libkdeinit_gwenview.so in *... ] media-gfx/digikam-0.9.1 (/usr/bin/digikam) media-gfx/digikam-0.9.1 (/usr/bin/showfoto) media-gfx/gwenview-1.4.1 (/usr/lib/libgwenviewcore.so.1.0.0) media-gfx/gwenview-1.4.1 (/usr/lib/libkdeinit_gwenview.so) media-gfx/gwenview-1.4.1 (/usr/bin/gwenview) media-plugins/digikamimageplugins-0.9.1 (/usr/lib/kde3/digikamimageplugin_adjustcurves.so) I played a little with the script revdep-rebuild and I found the following: The command: find /var/db/pkg -name CONTENTS | xargs fgrep -l -f .revdep-rebuild.3_rebuild in line 596 does not find any content. On my system /var/db/pkg is a symbolic link to the path /data/system/var/db/pkg (a partition with optimized filesystem for portage). I use it for PORTAGE_TMPDIR also. The find command is not executed with the parameter -L, so it does not follow any symlinks. The command find -L /var/db/pkg -name CONTENTS | xargs fgrep -l -f .revdep-rebuild.3_rebuild outputs correct /var/db/pkg/media-gfx/digikam-0.9.1/CONTENTS /var/db/pkg/media-gfx/gwenview-1.4.1/CONTENTS /var/db/pkg/media-plugins/digikamimageplugins-0.9.1/CONTENTS /var/db/pkg/media-plugins/kipi-plugins-0.1.3-r1/CONTENTS It seems, that this is the problem. I altered revdep-rebuild to use -L and now it works, until the next revision :)
I suggest to add the parameter -L in the internal find argument.
Exact same symptoms on my system, exact same soft-link as well :)
People, you really should use bind mounts for shuffling stuff around filesystem, NOT symlinks.
(In reply to comment #6) > People, you really should use bind mounts for shuffling stuff around > filesystem, NOT symlinks. While this may solve the problem in this case, it's very intrusive and not really equivalent to symlinks. I didn't see anyone using bind mounts with the introduction of x.org :)
(In reply to comment #7) > While this may solve the problem in this case, it's very intrusive and not > really equivalent to symlinks. I didn't see anyone using bind mounts with the > introduction of x.org :) Hmm, what's intrusive about it? o_O I just see lots of intrusive 'bugs' that users experience when shuffling stuff around for a lack of space via symlinks and wondering why they end up with a broken system, noexec /var/tmp being unable to emerge anything or whatever similar. Will never happen when you bind-mount the stuff properly.
(In reply to comment #7) > (In reply to comment #6) > > People, you really should use bind mounts for shuffling stuff around > > filesystem, NOT symlinks. > > While this may solve the problem in this case, it's very intrusive and not > really equivalent to symlinks. I didn't see anyone using bind mounts with the > introduction of x.org :) The situation with X.org is quite different: a) expected vs. unexpected b) system defined vs. user defined c) X.org doesn't have to care about file identity (not a real issue in this case, but one of the big problems when dealing with symlinks in portage) The problem might be trivial to solve in this specific case, but often it requires a lot more work to deal with symlinks in a transparent way, while bind-mounts (or normal mounts) handle the situation at the filesystem level, so we don't have to care about the issue at the application level.
Afaik symlinks are not banned for system administration and as it is a normal use for e.g. the make.profile under Gentoo at this point it should not be used. So the question that comes up is: "Why is /etc/make.profile" not a bind mount for regular use if symlinks are problematic?" An application should be able to handle symlinks on linux systems.
(In reply to comment #10) > Afaik symlinks are not banned for system administration and as it is a normal > use for e.g. the make.profile under Gentoo at this point it should not be used. Nobody said that they are banned, jsut that they can create a large nuber of problems in many situations, as they aren't as transparent as people tend to think. > So the question that comes up is: "Why is /etc/make.profile" not a bind mount > for regular use if symlinks are problematic?" Very similar to the X.org example above: a) it's expected to be a symlink. Problems mainly arise when symlinks are used in unexpected locations (usually to "solve" the "free space" issue) b) in this particular case a bind mount would be counter productive, as we care about the destination name (unlike how it's used here, where the destination should be hidden from the application) c) the link isn't really managed by the user but the system > An application should be able to handle symlinks on linux systems. Generally yes, the point is that handling symlinks everywhere adds quite a bit of complexity in many cases. In some cases it's also questionable how symlinks should be handled, e.g. if foo is a symlink to bla, should foo == bla be true? Depending on the use case the answer can be yes, no or maybe. Or to use this bug, it's not always a good idea to follow symlinks when processing directories, it can easily cause infinite loops, requiring even more complexity to avoid those (we had that with collision-protect for example). As said, in this case it's trivial to fix (but only because we can assume that /var/db/pkg itself doesn't contain links to unexpected locations), and should be fixed. However, if it would require an extensive patch, just for a very uncommon setup, I'd probably close it as WORKSFORME as there is a better solution available.
$ svn commit -m "Fix handling of /var/db/pkg when it is a symbolic link. (Bug #179392)" Sending ChangeLog Sending src/revdep-rebuild/revdep-rebuild Transmitting file data ..
Fixed in gentoolkit-0.2.4_rc1
