Bugzilla Bug 179392

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