On Apr 22, 2008, at 6:26 AM, devzero2000 wrote:

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

There are several confusions here. Yes rpmdeps uses exactly the same  
code
paths as rpmbuild uses internally, so examination of sort order of  
dependencies
by diffing with rpm --requires will show identical results.

Yes, grep/sed can post process the output of rpmdeps to filter  
unwanted dependencies.

Yes you can use other replacements for rpmdeps if you choose, and you  
can leave
off the sort at the end of scripts as Mandriva 2008.1 appears to have  
done.

Have it your own way! Have fun!

There are _STILL_ lossages, including
     1) files are not classified (i.e. rpm -qp --fileclass "breaks")
     2) dependencies are not attached to files (i.e. rpm -qp -- 
filerequires "breaks")
and
     3) files  do include elf32/elf64 bits aka colors.

Note that "colors" is just 2 bits that are more easily tested than  
using the file classification.
Even if you do not want multilib packaging, file classification in a  
database is useful imho.

There are no engineering reasons I am aware of for ELF systems  
(definitely true for linux, likely true
for others) to disable the internal dependency generator since RHL 8.  
There are other means to accomplish
whatever is needed, including manually adding all dependencies,  
filtering perl (and other interpreters)
using grep/perl, as well as turning off the execute bit (and using % 
attr to set for installs).

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

*shrug* and c'est la vie! are not the best engineering answers.

FWIW, I don't have a multilib system, and strongly recommend not  
using multilib systems with rpm,
the risks of build pollution are too high.

But there is much more than multilib that is tied to the setting of % 
use_internal_dependency_generator.

73 de Jeff