Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 37029 - revdep-rebuild doesn't rebuild when it should
Summary: revdep-rebuild doesn't rebuild when it should
Status: RESOLVED CANTFIX
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] Core system (show other bugs)
Hardware: All All
: High normal (vote)
Assignee: Portage Tools Team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2004-01-02 08:30 UTC by Blu3
Modified: 2005-12-03 07:20 UTC (History)
1 user (show)

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


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Blu3 2004-01-02 08:30:39 UTC
While trying to fix php-core that depends on sablotron, I discovered that it linked in libpq which for some reason is linking old ssl libraries even tho it doesn't exhibit it with ldd.  So I tried revdep-rebuild - but that seems to disagree with itself.  Several things are broken but in the end it thinks everything is fine.

# revdep-rebuild

Checking reverse dependencies...
Packages containing binaries and libraries broken by any package update,
will be recompiled.

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/lib/libexif-gtk.so.4.0.0 (requires libexif.so.8)
  broken /usr/lib/libpq.so.3.0 (requires libssl.so.0.9.6 libcrypto.so.0.9.6)
  broken /usr/lib/libgnomevfs.so.0.0.0 (requires libssl.so.0.9.6 libcrypto.so.0.9.6)
  broken /usr/lib/gphoto2/2.1.1/libgphoto2_directory.so (requires libexif.so.8)
  broken /usr/lib/gphoto2/2.1.1/libgphoto2_sierra.so (requires libexif.so.8)
  broken /usr/bin/ftp (requires libssl.so.0.9.6 libcrypto.so.0.9.6)
  broken /usr/bin/gtkam (requires libexif.so.8 libexif.so.8)
  broken /usr/bin/enlightenment-0.17 (requires libebits.so.1 libecore.so.0 libefsd.so.0 libebg.so.1 libevas.so.1 libeet.so.0 libedb.so.1)
  broken /usr/bin/ethereal (requires libcrypto.so.0.9.6)
  broken /usr/bin/anjuta (requires libssl.so.0.9.6 libcrypto.so.0.9.6 libssl.so.0.9.6 libcrypto.so.0.9.6)
  broken /usr/bin/dftest (requires libcrypto.so.0.9.6)
  broken /usr/bin/tethereal (requires libcrypto.so.0.9.6)
  broken /usr/X11R6/bin/uil (requires libMrm.so.3)
  broken /usr/X11R6/bin/xmanimate (requires libMrm.so.3)
  broken /usr/X11R6/bin/fileview (requires libMrm.so.3)
  broken /usr/X11R6/bin/hellomotif (requires libMrm.so.3)
  broken /usr/X11R6/bin/periodic (requires libMrm.so.3)
  broken /usr/X11R6/bin/helloint (requires libMrm.so.3)
  broken /usr/local/lib/libpq.so.3.0 (requires libssl.so.0.9.6 libcrypto.so.0.9.6)
  broken /usr/local/BlueList/BlueList (requires libbl_sql.so.0 libbl_smtp.so.0 libpq.so.2)
  broken /usr/local/old-powerix-apache/virtuals/blue-labs.org/4matty/vidcat (requires libpng.so.2)
  broken /opt/cxoffice/lib/wine/winenas.drv.so (requires libwine.so.1 libaudio.so.2)
  broken /opt/cxoffice/lib/wine/ttydrv.dll.so (requires libwine.so.1 libncurses.so.4)
 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.
#

Shouldn't at least some attempt be made to get some of those get fixed?
Comment 1 Blu3 2004-01-02 08:37:19 UTC
Further discovery in this process..

I've found that the lost links belong files of packages that gentoo thinks aren't installed anymore.  So far I've found two messed up sets.  PostgreSQL is installed and it's current libraries are 3.1, but there are 3.0 files remaining.  qpkg doesn't list any dupes for pgsql so these appear to be orphaned.  I've manually removed them.

Next, exif-gtk which exif is linked with.  The libraries and headers are installed, but gentoo thinks that exif-gtk isn't installed.  I'm rebuilding exif and exif-gtk now.

Does somebody have some tools or methods to find and remove or rebuild all of these orphans?
Comment 2 SpanKY gentoo-dev 2004-01-02 09:01:11 UTC
to be honest, if what you say is the case (all the files have been orphaned),
then from a portage stand point, there aint much you can do

just rm them and/or re-emerge them and  move on ;)
Comment 3 Blu3 2004-01-02 09:12:27 UTC
I've come across a -lot- of files in the last few hours that have been orphaned from old packages or packages that I know -I- installed but gentoo thinks they aren't installed.

A few idle questions that should be addressed for system integrity.

a) how are files becoming orphaned?
b) how are packages becoming lost?
c) how can these files and packages be identified as 'broken' for re-inclusion or removal?

If there exists a hidden problem in the system, we should try to keep an eye out for it now to identify and fix it.  As more time goes by, the system will just get more complex and make such things harder to find and fix.

Do any of the developers have scripts or tools for going through the whole system and doing integrity checks?  Verifying:

a) databases
b) existing files that appear orphaned
c) non-existing files that should be on the system
d) packages that should be removed or reinstalled
Comment 4 SpanKY gentoo-dev 2004-01-03 08:45:20 UTC
qpkg in gentoolkit will do a md5 check on installed files

portage wont uninstall a file if it has changed md5s or mtimes
Comment 5 Jakub Moc (RETIRED) gentoo-dev 2005-12-03 07:05:25 UTC
*** Bug 100207 has been marked as a duplicate of this bug. ***
Comment 6 Jakub Moc (RETIRED) gentoo-dev 2005-12-03 07:20:51 UTC
Closing CANTFIX, we can't rebuild something portage has no knowledge about (e.g.
orphaned files) and removal of cruft is not revdep-rebuild's task.