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
______________________________________________________________________
RPM Package Manager http://rpm5.org
Developer Communication List rpm-devel@rpm5.org
