On 02/03/2011 12:28 PM, Paul Howarth wrote:
> On 03/02/11 10:15, Panu Matilainen wrote:
>> On 02/03/2011 09:42 AM, Paul Howarth wrote:
>>> On Wed, 02 Feb 2011 19:59:07 -0500
>>> Tom Lane<tgl@xxxxxxxxxx> 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.
>
> The fedora-specific macros are endemic within the perl module packages
> (particularly arch-specific ones, where it's desirable to filter out .so
> provides for private objects) so perhaps it would be good to convert at
> least %perl_default_filter to use the new filtering capability in
> Rawhide (defined in macros.perl in the perl package).
Indeed, where possible the filtering macros should be updated to use rpm
built-in filtering + related features. What's there in rpm 4.9.0 is a
rather crude low-level mechanism that makes it /possible/ to filter, but
it might not be particularly user-friendly as is. Having helper macros
around it makes perfect sense (and I expect some "higher level" macros
to end up in rpm itself too eventually, they're just not there yet)
- Panu -
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
