On Apr 21, 2008, at 1:37 PM, Michael Jennings wrote:

> For various reasons, it is sometimes necessary to munge the
> automatically-generated Perl requirements for various packages.  The
> most common way to do that this I've found has been to set
> _use_internal_dependency_generator to 0, create a script which did
> something similar to this:
>
>     #!/bin/sh
>
>     /usr/lib/rpm/find-requires $* | grep -v 'perl(Business'
>
> and then redefine __find_requires to point to this script.
>
> As you might imagine, this technique breaks with RPM5.  The biggest
> and most obvious problem being that /usr/lib/rpm/find-requires no
> longer exists.  The closest thing is "/usr/lib/rpm/find-requires.perl"
> which contains only "exec /usr/lib/rpm/find-requires" and similarly
> fails.  Even %__find_requires points to this non-existent script.
>
> So the question is, what's the right way to "grep out" bogus Perl
> module dependencies in RPM >= 5.0?
>

Hmmm, ick. Disabling the internal depedency generator loses
sorted dependencies, and also results in uncolored packages that
will not install correctly on multilib platforms.

Have you tried using %__perl_requires instead of %__find_requires?
Same "grep -v" or "sed -e's/baddep//" filtering mechanism, just a
different macro.

What's more generally needed is a set of patterns applied to
filter _ALL_ dependencies. PLD has one of these thingies
(they're always first ;-) but now that rpmio/mire.c appears largely
finished, there's a better mechanism to filter _ALL_ deps.

What still needs some though is how to set up a build policy
configuration framework to configure patterns that you never want to
appear in packages. Otherwise lusers will be adding envvars, and options
and whatever else they think they need to change rpmbuild behavior.

73 de Jeff