__perl_requires misbehaving in rawhide (rpm or grep broken??)

Panu Matilainen pmatilai at laiskiainen.org
Thu Feb 3 10:15:02 UTC 2011


On 02/03/2011 09:42 AM, Paul Howarth wrote:
> On Wed, 02 Feb 2011 19:59:07 -0500
> Tom Lane<tgl at redhat.com>  wrote:
>
>> For the last week or so I've been getting broken-dependencies nagmail
>> about
>>
>> 	mysql-test-5.5.8-6.fc15.x86_64 requires perl(mtr_misc.pl)
>>
>> The depchecker is correct about that: the RPM built by koji shows an
>> unresolved dependency of that form.  The question is how that
>> dependency is getting past the __perl_requires filter that mysql.spec
>> uses, which looks like this:
>>
>> #!/bin/sh
>>
>> /usr/lib/rpm/perl.req $* | \
>>      grep -v -e "perl(th" \
>>      -e "perl(lib::mtr" -e "perl(lib::v1/mtr" -e "perl(mtr"
>>
>> What makes this especially weird is that the filter is working to the
>> extent of successfully removing several other symbols, including some
>> that match the "perl(mtr" pattern.
>>
>> This problem appeared after I built mysql 5.5.8-6 on 20-Jan.  The
>> dependency filter was working correctly in previous builds, the
>> latest being 5.5.8-5 on 13-Jan.  When I build the same SRPM locally
>> on my Fedora 13 box, no unexpected requires show up in the result.
>>
>> It's a bit hard to credit that grep itself is broken, not least
>> because it doesn't appear to have been rebuilt since October.  There
>> has been a fair amount of churn in rpm since 13-Jan, though.  Should
>> I file this as an rpm bug, or is there some other likely explanation?
>
> RPM 4.9 has made changes in the provides/requires extraction code that
> are not entirely backwards-compatible. One of these is in respect of
> perl dependency extraction where there is now %__perllib_requires as
> well as %__perl_requires. So you need to filter that as well as or
> instead of (as necessary) %__perl_requires. You'll need to be careful if
> you want the spec to be backwards compatible with older rpm versions
> though, where %__perllib_requires isn't defined.

Defining %__perllib_requires is safe as older rpm's simply don't use it 
for anything. However for rpm 4.9.0 you can use the built-in dependency 
filtering instead of redefining the scripts:

%__provides_exclude and %__requires_exclude can used to filter the 
results of generated dependencies, and %__provides_exclude_from and 
%__requires_exclude_from can be used to exclude entire files from 
dependency generation. These operate with regular expressions, eg
to filter all requires with 'mtr' in them you'd use something like

%define __requires_exclude .*mtr.*

or to stop provides generation for, say, private libraries, you could 
use something like

%define __provides_exclude_from ^%{_libdir}/mylib/.*\.so$

> Presumably you can't use
> http://fedoraproject.org/wiki/Packaging:AutoProvidesAndRequiresFiltering
> because this SRPM builds elf binaries.

Yup... the Fedora-specific filtering macros have various unwanted 
side-effects (due to using the external dependency generator mode) and 
should be phased out now that rpm has built-in support for filtering.

     - Panu -


More information about the devel mailing list