Thanks for the reply.

My interest was only in a better understanding of the RPM internal.

Personally as packager I never try not to disable the automatic deps
generation and use all the techniques that you have described in
alternative. I try to teach the same techniques to who I can, for RPM QA

Perhaps I have used it 8/9 years ago: i don't remember exactly what strange
proprietary SW i was packaging, only that
it had 4/5 JVM and 30000 files..............

So i am not personally interested to the undesired effects - e.g. loss of
scriptlet deps -  that I have described : if i had,  I would have proposed a
patch or at least a change proposal, i like the innovation.

Best Regards

On Tue, Apr 22, 2008 at 2:13 PM, Jeff Johnson <n3npq@mac.com> wrote:

>
> 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<http://www.nta-monitor.com/tools/arp-scan/download/%%7Bname%7D-%%7Bversion%7D.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
>