Bug 44966 - RPM find-provides script fails to find all that a package provides
Summary: RPM find-provides script fails to find all that a package provides
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: rpm-build (Show other bugs)
(Show other bugs)
Version: 7.1
Hardware: All Linux
Target Milestone: ---
Assignee: Jeff Johnson
QA Contact: David Lawrence
Depends On:
TreeView+ depends on / blocked
Reported: 2001-06-19 11:43 UTC by Adam Darney
Modified: 2007-04-18 16:33 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2001-08-06 14:37:08 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
tar file to demonstrate find-provides/find-requires bug (10.00 KB, application/x-tar)
2001-08-06 14:36 UTC, Adam Darney
no flags Details

Description Adam Darney 2001-06-19 11:43:54 UTC
From Bugzilla Helper:
User-Agent: Mozilla/4.76 [en] (X11; U; Linux 2.4.2-2 i686)

Description of problem:
When the SONAME field is missing from the ELF header, and a versioning file
was used (i.e. "gcc -shared -olibmylibrary.so
-Wl,--version-script,myversionscript mysource.o"  --Notice that the
optional -h flag is missing) find-provides doesn't recognise the versioning
info.  RPM builds the package file, but won't install it because
find-requires _DOES_ see the versioning info, and expects it to be there. 
For example:
find-provides produces: libmylibrary.so
find-requires produces: libmylibrary.so libmylibrary.so(VER2)
If executables or other shared libraries within the same RPM package are
dependent on libmylibrary.so, RPM will not install the package because
"libmylibrary.so(VER2)" can't be found even though it is actually provided
within that very same package file.  We have seen this problem starting at
RPM v3.0.4

How reproducible:

Steps to Reproduce:
1. Build a library without a SONAME field, but with versioning info
2. Build an executable that depends on that library
3. Package them up using RPM
4. Attempt to install the RPM package

Additional info:

The following solution is a replacement for the current find-provides.  If
the SONAME field is absent, it correctly defaults its value to the
filename.  I also moved the check for the symlink files to improve
performance.  I am not sure why the original author uses "file -L", since
the file will only be thrown away by the later check to filter out symbolic
links.  Here is the code:

# This script reads filenames from STDIN and outputs any relevant provides
# information that needs to be included in the package.

filelist=$(grep "\\.so" | grep -v "^/lib/ld.so" | xargs file -L 2>/dev/null
| grep "ELF.*shared object" | cut -d: -f1)

for f in $filelist; do
    if [ ! -L $f ]; then
        soname=$(objdump -p $f | awk '/SONAME/ {print $2}')

        if [ -z "$soname" ]; then
        echo $soname
        objdump -p $f | awk '
            BEGIN { START=0 ; }
            /Version definitions:/ { START=1; }
            /^[0-9]/ && (START==1) { print $4; }
            /^$/ { START=0; }
            ' | \
        grep -v $soname | \
        while read symbol ; do
            echo "$soname($symbol)"
done | sort -u

Comment 1 Jeff Johnson 2001-07-29 16:11:57 UTC
Can you provide a detailed example please, including package(s)
that exhibit the problem/feature? Since dependencies have a global scope
across arch and distro far beyond the find-requires script, I need to see the
more specifically in order to compute the ramifications of changing
the automagic find-requires script.

Comment 2 Adam Darney 2001-08-06 10:23:00 UTC
I will provide a small example ASAP

Comment 3 Adam Darney 2001-08-06 13:06:48 UTC
This problem is not recreatable with RPM v4.0.2 as is, because the find-requires
script has been changed to only to require GLIBC_* version labels.  This seems
more than a bit peculiar.  So, the find-provides and find-requires scripts are
still not symmetric, but the only way to recreate this particular problem now
would be to give a version label with GLIBC_*.  While theoretically possible,
from a real-world standpoint, it doesn't seem plausible.  This is still a
problem in RPM v3.0.4 (RH 6.2), and perhaps later RPM's which I don't have
access to, nor do I know which ones are still being actively maintained.  It
appears that I've opened this against RH7.1, but it was probably initially
discovered a few months ago on a beta of RH7.0, which I no longer have.  I
should have double-checked the RH & RPM versions before opening this against
RH7.1.  In my opinion only, find-provides and find-requires are still both
broken but I don't know if this should be pursued under this bug, or pursued at
Please advise.

Comment 4 Jeff Johnson 2001-08-06 13:15:01 UTC
Again, I need an expliciit example of a provide/require that is not
being generated correctly from some (hopefully rpm-4.0.3) version
of rpm to even begin to assess the impact of a change to

Comment 5 Adam Darney 2001-08-06 14:33:02 UTC
Attached is an example of the original problem, the only difference is that I
changed the version labels to GLIBC_666 because of the peculiar way
find-requires was changed.  Commands to demonstrate:
"tar -xvf mypkg.tar; make install"

Comment 6 Adam Darney 2001-08-06 14:36:58 UTC
Created attachment 26418 [details]
tar file to demonstrate find-provides/find-requires bug

Comment 7 Jeff Johnson 2001-08-24 17:01:32 UTC
I'll look at this soon after rpm-4.0.3 is released, as changes to the
dependency generation scripts need to be carefully thought about.

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