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): compat-db-4.0.14-5.1 How reproducible: Always Steps to Reproduce: 1. install compat-db 2. rpm -V compat-db 3. 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:
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 ***