RSS Feed for This PostCurrent Article

Odd RPM Dependencies

By Christopher Blunck on Jan 16, 2007 in News Items

We’re finalizing the Zenoss 1.1 core product, and part of this process involves the creation of distribution RPMs. We then take those RPMs and install them on various servers in our lab in order to shake-out the software and verify that the software operates as we expect it to. A strange dependency has arisen in the RPM, and I thought I’d blog about it to see if anyone posts a comment with an idea of how this dependency was created.

When we build the rrdtool package we pass –disable-perl as an option to the configure script. Then we run make, followed by make install. When rpmbuild creates the RPM it walks through the directories and determines what dependencies our RPM depends on. This is where the black magic (and problems) occur. I don’t understand how rpmbuild creates this dependency list but it started adding perl(RRDs) and perl(RRDp) to the list.

My first thought was that rpmbuild looked for .so files, and then ran ldd against them to see what they are linked against. Then it cross-referenced that list with the list of installed files, and from that list then determined that our RPM depends on another package. The problem with that logic is that none of our .so files are linked against anything related to perl or perl-rrdtoolmodule.

I eventually traced it down to some .pl example files that rrdtool installs even tho you say –disable perl.  I suspect that rpmbuild looks at all files, including ones ending in .pl, and then has some logic built into it that looks to see what modules are being loaded.  How rpmbuild makes the leap from an import of rrdtool in perl to perl(RRDs) and perl(RRDp) is beyond me.

If you have some ideas or know how rpmbuild does it’s dependency determination magic I would like to know more…

Sphere: Related Content

Trackback URL

RSS Feed for This Post5 Comment(s)

  1. Eric-Olivier Lamey | Jan 25, 2007 | Reply

    The internal rpmbuild dependency generator will indeed search perl script and find out what perl rpm packages are
    needed. In rrdtool’s case, the generator will see script with ‘use RRDs’ and ‘use RRDp’. One way to solve the problem is to manually delete the perl script after the %build part or during the %install part.
    Another way is to override the depency generator with your own. In the spec file:

    %define _use_internal_dependency_generator 0
    %define __find_requires %{SOURCE900}
    Source900: filter-requires

    In the sources dir, a script called filter-requires (for exemple):

    #!/bin/bash

    /usr/lib/rpm/find-requires "$@" \
    | grep -v 'perl(RRDs)' \
    | grep -v 'perl(RRPd)'

  2. Christopher Blunck | Jan 26, 2007 | Reply

    Eric-Olivier,

    Thanks for the comment!

    I came to the same conclusion as you describe in your comment. In our .spec file we remove the example perl scripts. We were perplexed by why our 1.0.2 RPM didn’t have the perl(RRDs) dependency but 1.1.0 did - we upgraded rrdtool, but those example perl scripts also exist in the older version of rrdtool and in the 1.0.2 RPM.

    Thanks for pointing out the custom filter hook. I’m going to keep that in mind for use in the future. We currently build on CentOS 4.3 and that seems to be compatible with FC6, RHEL4.3, and SLES 10.1. But I’m feeling like in the future we might not be compatible as a result of the deps find-requires calculates (for example, maybe a perl RPM for SLES 11 won’t report that it provides some name that the same RPM for CentOS 4.3 says it provies), and if that happens I’ll probably end up writing a custom filter as you suggest.

    Thanks again for the comment… Sometimes I feel like the rpmbuild stuff is black magic!

  3. Eric-Olivier Lamey | Jan 27, 2007 | Reply

    Crhistopher,

    Although packages built on CentOS might seem compatible across different distributions, I would highly suggest building them on a clean build server, one for each distro/version. The dependencies might have the same name, but the libraries are certainly different. The only compatibility you can get is between CentOS X.X and RHEL X.X. Having those build server is just a matter of installing a few virtual machines and setting up some basic scripts to build and upload the RPMs.

  4. Christopher Blunck | Jan 29, 2007 | Reply

    Eric-Olivier,

    Your comment about separate buildhosts is well taken. It’s been on my TODO list, but our hardware budget is pretty limited at the moment. I’m competing for computing resources with the other developers too. If sure that if we had RPM users on different distros complaining about incompatibilities that it would serve as a catalyst for setting up additional build hosts.

  5. Z>m | Jun 11, 2008 | Reply

    Awesome!!!

    I fixed a circular dependency building python from a source tgz with this filter:

    #!/bin/bash

    # working around a circular dependency on python executable
    /usr/lib/rpm/find-requires "$@" | egrep "\.py$"

    I referenced it pretty much exactly as above:

    # eliminate circular dependency
    %define _use_internal_dependency_generator 0
    %define __find_requires %{SOURCE900}
    Source900: %{name}-filter-requires

    What a lifesaver.
    Thanks—Z>m

RSS Feed for This PostPost a Comment