[opensuse-packaging] Use of icedtea in 11?
Hi, I'm currently working on update of some java packages from OBS project Java:jpackage-1.7 to stable. So I'm also trying to build some of these packages with icedtea. Some of them should be builded (like adaptx) with small patches, some of them currently not (like hsqldb). But the switch to icedtea is not an automated process anymore, so if the autobuild team switches the compiler, majority of java packages will not be builded and needs to do some patches or revert back to the non free compiler. I can update a package and try to build it by icedtea, so I'm be able to switch the BuildRequire to java-1_7_0-icedtea-devel, if it works. The problem is, that the icedtea is only for i386 and a x86_64 available. On ppc or s390 we are using an IBM's compiler only. But a majority of a java packages is noarch, because a Java bytecode is architecture indepentent. I'm not sure, if I should use something like %ifarch %ix86 x86_64 BuildRequires: java-1_7_0-icedtea-devel %else BuildRequires: java-devel %endif in a spec file for noarch packages. May I try to build the most of java packages using icedtea? And if yes, how to do that? Use of the %ifarch in spec? Regards Michal Vyskocil --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On Thursday 28 February 2008 16:49:10 wrote Michal Vyskocil:
Hi,
I'm currently working on update of some java packages from OBS project Java:jpackage-1.7 to stable. So I'm also trying to build some of these packages with icedtea.
Some of them should be builded (like adaptx) with small patches, some of them currently not (like hsqldb). But the switch to icedtea is not an automated process anymore, so if the autobuild team switches the compiler, majority of java packages will not be builded and needs to do some patches or revert back to the non free compiler. I can update a package and try to build it by icedtea, so I'm be able to switch the BuildRequire to java-1_7_0-icedtea-devel, if it works.
The problem is, that the icedtea is only for i386 and a x86_64 available. On ppc or s390 we are using an IBM's compiler only. But a majority of a java packages is noarch, because a Java bytecode is architecture indepentent. I'm not sure, if I should use something like
%ifarch %ix86 x86_64 BuildRequires: java-1_7_0-icedtea-devel %else BuildRequires: java-devel %endif
That should not be needed, we can map java-devel to the correct java version in the distribution configurations. Acctually, you should not BuildRequire a certain java version at all, as long you do not want to enforce the exclusive use with this version. Better use java-devel everywhere and tell us, which java version by default should be selected dependening on the architecture.
in a spec file for noarch packages.
May I try to build the most of java packages using icedtea? And if yes, how to do that? Use of the %ifarch in spec?
openSUSE:Factory project does build against icedtea already. No need for a ifarch. bye adrian -- Adrian Schroeter SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) email: adrian@suse.de --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Adrian Schröter wrote:
On Thursday 28 February 2008 16:49:10 wrote Michal Vyskocil: [...] That should not be needed, we can map java-devel to the correct java version in the distribution configurations.
...which only works in the OBS.
Acctually, you should not BuildRequire a certain java version at all, as long you do not want to enforce the exclusive use with this version.
Right, the typical requirement is "I want Sun JDK version >= x.x.x" ;) (at least on ix86 and x86_64).
Better use java-devel everywhere and tell us, which java version by default should be selected dependening on the architecture.
But that has to be provided by the packages themselves, not (only) by
OBS tricks.
cheers
- --
-o) Pascal Bleser http://linux01.gwdg.de/~pbleser/
/\\
On Sunday 02 March 2008 00:08:45 wrote Pascal Bleser:
Adrian Schröter wrote:
On Thursday 28 February 2008 16:49:10 wrote Michal Vyskocil:
[...]
That should not be needed, we can map java-devel to the correct java version in the distribution configurations.
...which only works in the OBS.
The selection of a specific one, yes. But java-devel is provided by the java package.
Acctually, you should not BuildRequire a certain java version at all, as long you do not want to enforce the exclusive use with this version.
Right, the typical requirement is "I want Sun JDK version >= x.x.x" ;) (at least on ix86 and x86_64).
But this should be done only, if it is sure that this is the single java version which does work. In general all java version should work for almost all java packages. Therefore it is better to use java-devel .
Better use java-devel everywhere and tell us, which java version by default should be selected dependening on the architecture.
But that has to be provided by the packages themselves, not (only) by OBS tricks.
A java package should in general work with all java versions, otherwise we can never upgrade a java or switch to some other java. This is esp. important when it comes to other architectures, Sun Java does not exist for all. So an explicit requirement to Sun java would mean that your java package needs to get disabled on these architectures. -- Adrian Schroeter SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) email: adrian@suse.de --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
* Adrian Schröter
In general all java version should work for almost all java packages. Therefore it is better to use java-devel .
In an ideal world or in reality? Do you have a statistics about that statement? Especially for desktop applications that make use of Swing. E.g. http://forums.fedoraforum.org/archive/index.php/t-178068.html ,----- | 2) Forget IcedTea, disable Selinux, install Sun's java, and use | standard jarfiles to install the applications you require. I have not | tested this approach on Fedora 8, but it worked fine for jEdit and | Squirrel SQL on Fedora 7. If you require a proprietary JDBC driver to | connect to a database, how likely is it to have been tested against | IcedTea? `----- Or are you talking *only* abuild building, not running?
Better use java-devel everywhere and tell us, which java version by default should be selected dependening on the architecture.
But that has to be provided by the packages themselves, not (only) by OBS tricks.
A java package should in general work with all java versions, otherwise we can never upgrade a java or switch to some other java. This is esp. important when it comes to other architectures, Sun Java does not exist for all. So an explicit requirement to Sun java would mean that your java package needs to get disabled on these architectures.
Of course -- but I guess IBM Java 1.5 on POWER/Seriesz and BEA Java on IA64 is fully or nearly (99.9 %) compatible with Sun Java 1.5, but Sun Java 1.4 is not to 1.5, of course, -- so versioning is important while the vendor is not necessarily important. Bernhard --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Adrian Schröter wrote:
On Sunday 02 March 2008 00:08:45 wrote Pascal Bleser:
Adrian Schröter wrote:
On Thursday 28 February 2008 16:49:10 wrote Michal Vyskocil: [...]
That should not be needed, we can map java-devel to the correct java version in the distribution configurations. ...which only works in the OBS.
The selection of a specific one, yes. But java-devel is provided by the java package.
Ok
Acctually, you should not BuildRequire a certain java version at all, as long you do not want to enforce the exclusive use with this version.
Right, the typical requirement is "I want Sun JDK version >= x.x.x" ;) (at least on ix86 and x86_64).
But this should be done only, if it is sure that this is the single java version which does work. In general all java version should work for almost all java packages. Therefore it is better to use java-devel .
Not quite true. When you compile Java source code, you must always be able to say "I need JDK version 1.4.2|5.0|6.0". Best is to use the exact needed version, but if you compile Java code that doesn't require 5.0 with JDK 5.0, it will work on a 1.4.2 JRE at runtime. The issues involved here is that * (l)build doesn't know about versioned BuildRequires, at least the last time I checked (e.g. BuildRequires: java-devel >= 1.5.0) * you almost always want to use the Sun JDK, not GCJ (as much as I respect the work of the GCJ/GNUClasspath/Kaffe/etc.. developers, it won't work for most Java projects) Well.. Sun or IBM, depending on the platform (Sun where available). Maybe adding a sun-java-devel Provides would help (if the BuildRequires resolution of (l)build works properly on Provides)
Better use java-devel everywhere and tell us, which java version by default should be selected dependening on the architecture. But that has to be provided by the packages themselves, not (only) by OBS tricks.
A java package should in general work with all java versions, otherwise we can never upgrade a java or switch to some other java. This is esp. important when it comes to other architectures, Sun Java does not exist for all. So an explicit requirement to Sun java would mean that your java package needs to get disabled on these architectures.
That's two different things.
On the version, it's actually the opposite. You have some Java sources.
If they use Tiger (Java 5.0) features (generics, varargs, new for loops,
...), you _must_ have a JDK >= 1.5.0 to compile that.
OTOH if you have Java sources that don't use 5.0 features and compile
with 1.4.2, you can compile them with JDK 5.0, no problem here, and the
resulting JVM bytecode will even be backwards compatible with 1.4.2 at
runtime. But the opposite is not true: if the sources use Java 5
features, then the bytecode will only run on JRE >= 5.0.
The other topic is architectures without a Sun JDK, such as PPC.
The point is rather use Sun or IBM, but not GCJ/GNUClasspath.
And AFAICR, GCJ also "Provides: java-devel"
So the option is.. what, this?
%ifarch %ix86 x86_64
BuildRequires: java-devel-sun >= 1.5.0
%else
BuildRequires: ...IBM...
%endif
or this?
%ifarch %ix86 x86_64
BuildRequires: java-1_5_0-sun-devel
%else
BuildRequires: ...
%endif
See my point ? ;)
cheers
- --
-o) Pascal Bleser http://linux01.gwdg.de/~pbleser/
/\\
participants (4)
-
Adrian Schröter -
Bernhard Walle -
Michal Vyskocil -
Pascal Bleser