Bug 150241

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.

*** Bug 150239 has been marked as a duplicate of this bug. ***

*** Bug 150240 has been marked as a duplicate of this bug. ***

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.

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.

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.

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? 

This appears to be the same as bug 145728

Adding to proposed list.

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