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


I am sure that i have missing something here, but the arguments is rilevant.
There is the necessity to doing RPM for  incorrectly built
proprietary SW e sometime it is necessary to disabling the internal dep
generator.

I attach a sample rpm spec that i have build with rpm5. It does something
like :

Name:           arp-scan
Version:        1.6
Release:        1%{?dist}
Summary:        Scanning and fingerprinting tool

Group:          Applications/Internet
License:        GPL
URL:            http://www.nta-monitor.com/tools/arp-scan/
Source0:
http://www.nta-monitor.com/tools/arp-scan/download/%{name}-%{version}.tar.gz

Source91:  filter-requires-%{name}.sh
Source92:  filter-provides-%{name}.sh
%define    _use_internal_dependency_generator 0
%define    __find_requires %{SOURCE91}
%define    __find_provides %{SOURCE92}
.
.


Where filter-requires-arp-scan.sh contain :

#!/bin/sh
[ ! -x  /usr/lib/rpm/rpmdeps ] && exit 0
 /usr/lib/rpm/rpmdeps -R $* |\
  sed -e '/^bar(baz)$/d


Just for test of course.

Now the deps produced with or no disabling the internal dependency generator
have  the same ordering, al least
in this case: is it just a case ?

Sure, in setting  _use_internal_dependency_generator to 0 i lose the
automatics deps on scriptlet too, but it is life.
It would be useful to know which it is the problem of the support multilib
and wrong color: i haven't a multilib system now
for doing test.

Thanks in advance

On Mon, Apr 21, 2008 at 7:53 PM, Jeff Johnson <n3npq@mac.com> wrote:

>
> 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
>