Re: SOURCES: rpm-macros.java - do not use internal dependency generator
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. -- Jakub Boguszhttp://qboosh.pl/ ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: SOURCES: rpm-macros.java - do not use internal dependency generator
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. Correct. AFAIK, rpm-4.4.8 classifies (by suffix, not perfect) .jar and .class files: Here's lib/rpmfc.c code: ... /* XXX all files with extension .jar are java archives for now. */ else if (_suffix(s, .jar)) ftype = Java archive file; /* XXX all files with extension .class are java class files for now. */ else if (_suffix(s, .class)) ftype = Java class file; 73 de Jeff ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: SOURCES: rpm-macros.java - do not use internal dependency generator
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
[...]
real0m13.337s
user0m5.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
real0m7.877s
user0m1.750s
sys 0m0.670s
--
glen
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: SOURCES: rpm-macros.java - do not use internal dependency generator
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
[...]
real0m13.337s
user0m5.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
real0m7.877s
user0m1.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
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
