Bug 150241 - compat-db contains a broken symlink which is immediately removed by ldconfig in %post
Summary: compat-db contains a broken symlink which is immediately removed by ldconfig ...
Status: CLOSED DUPLICATE of bug 145728
Alias: None
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: compat-db
Version: 3.0
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Paul Nasrat
QA Contact:
: 150239 150240 (view as bug list)
Depends On:
TreeView+ depends on / blocked
Reported: 2005-03-03 21:48 UTC by David Lehman
Modified: 2007-11-30 22:07 UTC (History)
4 users (show)

Clone Of:
Last Closed: 2005-10-12 14:27:13 UTC

Attachments (Terms of Use)

Description David Lehman 2005-03-03 21:48:05 UTC
Description of problem:
compat-db contains the following symlink:
lrwxrwxrwx    1 root    root               11 Sep 30 15:29 /usr/lib/libdb.so.3
-> libdb2.so.3

However, libdb2.so.3 is in /lib, not /usr/lib. So ldconfig removes it
immediately and creates the correct link named libdb.so.3 in /lib.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. install compat-db
2. rpm -V compat-db
Actual results:
-bash-2.05b$ rpm -V compat-db
missing    /usr/lib/libdb.so.3

Expected results:
Successful verify of just-installed package

Additional info:

Comment 1 David Lehman 2005-03-03 21:53:01 UTC
Based on the specfile it looks like it should also move the rest of the shared
libs from %{_libdir} into %{_lib}. Right now it's kind of mixed up.

Comment 2 Jeff Johnson 2005-03-03 22:38:51 UTC
*** Bug 150239 has been marked as a duplicate of this bug. ***

Comment 3 Jeff Johnson 2005-03-03 22:39:43 UTC
*** Bug 150240 has been marked as a duplicate of this bug. ***

Comment 4 Jeff Johnson 2005-03-03 22:48:36 UTC
Yes, there is a hysterical confusion trying to provide
a legacy symlink in /usr/lib when libdb-x.y.so has been
in /lib a very long time now. New behavior of ldconfig
is preventing the hysterical legacy retrofit.

Meanwhile, the problem is mostly harmless, as compat-db
is intended to satisfy soname linkage for 3rd party built
packages, which should be quite happy to find the symlink
in either /lib or /usr/lib at run-time. Note carefully that
compat-db is intended to supply only a binary library, there
is explicitly no attempt to provide multiple db packages for
linking older versions of Berkeley db during build using
compat-db supplied libraraies. Porting to the system db
is the recommended solution for rebuilding.

Comment 5 James Olin Oden 2005-03-04 16:46:56 UTC
The problem of the symlink being a dangling link and thus removed
anytime ldconfig is ran is actually not harmless if a rollback of the
package is attempted.  If you rollback to package that when repacked
was missing files, when rpm begings delivering the files it will croak
on a cpio error, and the rollback will not continue.

My vote would be to simply remove the symbolic links, or if they are
needed make them correct (or fix it so a repackeged package with
missing files does not cause the whole rollback to die...or even the
rollback of that package; after all repackage package is supposed to
contain the current header, and what is actually on the system, so if
the files weren't on the system why die?  I know its more complicated
than that (otherwise I would have fixed this by now)).

Anyway,  at least for me this is a real problem, and not just an anoyance.

Comment 6 Mike Loseke 2005-03-16 15:37:55 UTC
I, for one, don't find it very 'hysterical'.

 The use of the OS with regards to these libs, at least in my case, is as an
end-user of a tool rather than as a developer. I understand how to link libs in
applications but the 3rd party tool we're using, which uncovered the issue,
seems to rely on this specific library being found in the exact location that is
being removed. Recompiling, relinking and porting forward are not options in
this instance. This is why, at least for my part, I opened the ticket which is
now a bug. Fixing the bug so as to deliver all files and symlinks as intended
should be the sole focus of the work being done to resolve the issue.

Comment 7 Pat Russell 2005-05-26 00:15:42 UTC
Am I missing something here?  What we have is a file /lib/libdb2.so.3.  Then 
after ldconfig is done we have a link /lib/libdb.so.3 that points libdb2.so.3 
(because it's in the same directory).  Then we have end-user tools that are 
looking for /usr/lib/libdb.so.3 but failing to find it.  We also have "rpm -V" 
looking for the same entry and not finding it.

I also see a link /usr/lib/libdb.so that points to ../../lib/libdb-4.1.so so 
the tools know how to handle a ../../lib/* link.

So why not put out a new version of the compat-db package that would put a link 
to ../../lib/libdb2.so.3 as /usr/lib/libdb.so.3 and a link to libdb2.so.3 
as /lib/libdb.so.3.  This would cause the end-user tools to work if they are 
looking for either /lib/libdb.so.3 or /usr/lib/libdb.so.3.

And many people do not need the compat-db package so they are not affected as 
none of these files or links would be present on their systems.  Eventually the 
end-user tools will get updated and should no longer need the compat-db package 
so the problem will eventually go away.  The cost of this solution that I see 
is an additional link, a pretty small price.

The benfits include "rpm -V" running cleanly, rollback working, and the end-
user tools working.  I am not an expert on this sort of thing.  Is there some 
gotcha I don't know about? 

Comment 8 Guy Streeter 2005-09-01 18:57:26 UTC
This appears to be the same as bug 145728

Comment 9 Paul Nasrat 2005-10-12 14:04:07 UTC
Adding to proposed list.

Comment 10 Paul Nasrat 2005-10-12 14:27:13 UTC

*** This bug has been marked as a duplicate of 145728 ***

Note You need to log in before you can comment on or make changes to this bug.