[Rpm-maint] How to prevent rpmbuild from including dependencies on non-rpm libraries

James Olin Oden james.oden at gmail.com
Wed Feb 7 16:54:52 UTC 2007


On 2/6/07, Dr. Douglas C. MacKenzie <doug at mobile-intelligence.com> wrote:
> We are using Fedora Core 6, and rpm version 4.4.2-32.
>
> We use some libraries which are not provided as RPM files.
> An example is the Intel IPP library, which is a tar file that just
> installs libraries directly in /opt/intel
>
> My problem is our software is packaged as RPM files.  When I create an
> rpm from our software rpmbuild finds the dependency on the IPP libraries
> (from *_la_LIBADD in the Make.am file, I guess) and adds them to the
> binary RPM package.  When I try to install the binary package, I get
> errors like these:
>
> error: Failed dependencies:
>        libippacem64t.so.5.1()(64bit) is needed by
> miVideo-devel-1.1-3.x86_64
>        libippccem64t.so.5.1()(64bit) is needed by
> miVideo-devel-1.1-3.x86_64
>        libippcoreem64t.so.5.1()(64bit) is needed by
> miVideo-devel-1.1-3.x86_64
>        libippcvem64t.so.5.1()(64bit) is needed by
> miVideo-devel-1.1-3.x86_64
>        libippiem64t.so.5.1()(64bit) is needed by
> miVideo-devel-1.1-3.x86_64
>        libippjem64t.so.5.1()(64bit) is needed by
> miVideo-devel-1.1-3.x86_64
>        libippmem64t.so.5.1()(64bit) is needed by
> miVideo-devel-1.1-3.x86_64
>        libippscem64t.so.5.1()(64bit) is needed by
> miVideo-devel-1.1-3.x86_64
>        libippsem64t.so.5.1()(64bit) is needed by
> miVideo-devel-1.1-3.x86_64
>        libippsrem64t.so.5.1()(64bit) is needed by
> miVideo-devel-1.1-3.x86_64
>        libippvcem64t.so.5.1()(64bit) is needed by
> miVideo-devel-1.1-3.x86_64
>        libippvmem64t.so.5.1()(64bit) is needed by
> miVideo-devel-1.1-3.x86_64
>
Work could be done to do what your talking about.   The problem is it
appears that no one has interest or time (both have to be in
alignment;
my issue is more time).  I've often thought being able to specifically
filter out
certain autogenerated dependencies would be a very nice feature.  As
it is though
unless you can get someone with the time interested you'd probably
have to provide said patch yourself.

Now that being said there is a work around, which though ugly is
doable.  Find one of the perl-TK SRPM's and you will see how they
redefine the macro that is used to generate the autogenerated
dependencies, to be what it used to be but piped into "grep -v".

The trick is simple in that all the autogenerated dep tools generate lines like:

   perl(Blah::Blah)
   libclient.so.1

and so on, such that one can easily replace them with something that
calls them and filters out the lines you don't care about.

Yes its a hack and its ugly but its the best that can be done at the present

Cheers...james

P.S. In the other fork of rpm much work is being done to supply
runtime probes for dependencies.  I have no idea what this fork's
maintainers think about that.  IMO its a usefull feature that still
needs much thought before unleashing, and certainly it should be
highly configurable (i.e. some times for some things it may not always
be desirable that they be probed).

P.S.S.  Concerning your unpackaged libraries, you can create binary only SRPMS.



More information about the Rpm-maint mailing list