SOURCES: rpm-macros.java - do not use internal dependency generator

[Jeff Johnson]

On Apr 10, 2007, at 5:22 PM, Elan Ruusamäe wrote:

> On Tuesday 10 April 2007, Jeff Johnson wrote:
>> On Apr 10, 2007, at 2:38 PM, Jakub Bogusz wrote:
>>> On Wed, Apr 04, 2007 at 01:02:45PM +0200, glen wrote:
>>>> Author: glen                         Date: Wed Apr  4 11:02:45
>>>> 2007 GMT
>>>> Module: SOURCES                       Tag: HEAD
>>>> ---- Log message:
>>>> - do not use internal dependency generator
>>>>
>>>> +# rpm itself doesn't recognize .jar and .class
>>>> +%define	_use_internal_dependency_generator  0
>>>
>>> So it cannot be used on any package containing ELF files.
>>> External generators cannot properly mark file colours.
> yes. that was just there to get it started ;)
>
>> Correct.
>>
>> AFAIK, rpm-4.4.8 classifies (by suffix, not perfect) .jar and .class
>
> appears that (at least rpm 4.4.2) calls rpmfcSCRIPT for each file.
> could rpmbuild invoke the requires/provider script only once  
> passing (in STDIN) all the file from the same class.
>
> it could speedup the packaging stage. for example script for  
> pythondeps is able to cache $PYVER:
>
> $ time rpmbuild --short-circuit --define '_source_payload w9.gzdio'  
> -bb --define 'clean %{nil}' smart.spec
> [...]
> real    0m13.337s
> user    0m5.130s
> sys     0m2.790s
>
> and after changing just to PYVER=2.4:
>
> $ time rpmbuild --short-circuit --define '_source_payload w9.gzdio'  
> -bb --define 'clean %{nil}' smart.spec
> real    0m7.877s
> user    0m1.750s
> sys     0m0.670s
>

Yep. Major reworking would need to be done to batch entries however.

What needs to be established first is the reliability and usefulness  
of per-interpreter dependency
extraction. There's hardly a need to speed up extraction for seldom  
used unreliable functionality.

73 de Jeff