(also posted to fedora-devel)
Two questions:
- Who should own /usr/share/java? Currently there is:
libidn-devel.i386 jpackage-utils.noarch java-1.5.0-gcj-javadoc.i386 libgcj-src.i386 libgcj.i386 java-1.4.2-gcj-compat-javadoc.i386 kdevelop.i386 db4-java.i386 axis-javadoc.i386 swig.i386 jlex.i386 antlr-javadoc.i386 xdoclet-javadoc.i386
and that's just from core.
- Where should JNI libraries be installed? plplot wants to install into /usr/lib/jni, but that doesn't look like it's used by anyone else.
Thanks!
Orion Poplawski wrote:
(also posted to fedora-devel)
Two questions:
- Who should own /usr/share/java? Currently there is:
libidn-devel.i386 jpackage-utils.noarch java-1.5.0-gcj-javadoc.i386 libgcj-src.i386 libgcj.i386 java-1.4.2-gcj-compat-javadoc.i386 kdevelop.i386 db4-java.i386 axis-javadoc.i386 swig.i386 jlex.i386 antlr-javadoc.i386 xdoclet-javadoc.i386
and that's just from core.
Ouch! I think jpackage-utils is the right answer and everything else is a bug.
- Where should JNI libraries be installed? plplot wants to install into
/usr/lib/jni, but that doesn't look like it's used by anyone else.
I believe most end up in %{_libdir}.
AG
Anthony Green writes:
Orion Poplawski wrote:
(also posted to fedora-devel)
Two questions:
- Who should own /usr/share/java? Currently there is:
libidn-devel.i386 jpackage-utils.noarch java-1.5.0-gcj-javadoc.i386 libgcj-src.i386 libgcj.i386 java-1.4.2-gcj-compat-javadoc.i386 kdevelop.i386 db4-java.i386 axis-javadoc.i386 swig.i386 jlex.i386 antlr-javadoc.i386 xdoclet-javadoc.i386
and that's just from core.
Ouch! I think jpackage-utils is the right answer and everything else is a bug.
I don't think so. gcj installs in /usr/share/java, and I don't want it to depend on jpackage.
Andrew.
Andrew Haley wrote:
I don't think so. gcj installs in /usr/share/java, and I don't want it to depend on jpackage.
Well, there may be no good answer then, since the distro currently includes many jpackages which do not currently depend on gcj.
Why do you not want to depend on jpackage-utils?
AG
Anthony Green writes:
Andrew Haley wrote:
I don't think so. gcj installs in /usr/share/java, and I don't want it to depend on jpackage.
Well, there may be no good answer then, since the distro currently includes many jpackages which do not currently depend on gcj.
Why do you not want to depend on jpackage-utils?
I'm not sure, really. I guess it's a small package, so I guess I could live with it.
Andrew.
Le lundi 26 mars 2007 à 18:47 +0100, Andrew Haley a écrit :
Anthony Green writes:
Andrew Haley wrote:
I don't think so. gcj installs in /usr/share/java, and I don't want it to depend on jpackage.
Well, there may be no good answer then, since the distro currently includes many jpackages which do not currently depend on gcj.
Why do you not want to depend on jpackage-utils?
I'm not sure, really. I guess it's a small package, so I guess I could live with it.
jpackage-utils is a bunch of default directories, rpm macros to map them, a few helper shell scripts to use these dirs and documentation
It's only there to provide a central place for java packaging policy (policy that can be amended/expanded @jpackage, it's not set in stone, I wrote some central parts of it alone in three week-ends a few years ago)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Andrew Haley wrote:
I don't think so. gcj installs in /usr/share/java, and I don't want it to depend on jpackage.
RPM allows multiple packages to own the same directory, so I don't know what the big deal is.
I would think that you would want to depend on jpackage-utils for the correct macros like %{_javadir} for libgcj.jar and %{_jvmdir} for `--with-java-home'. I guess you could fake these, but luckily jpackage-utils should be a msall package with no other dependencies.
- -- Sincerely,
David Walluck david@zarb.org
On Mon, Mar 26, 2007 at 10:33:26AM -0700, Anthony Green wrote:
I believe most end up in %{_libdir}.
Aren't jni files dlopened? If it is the case they should not be in %{_libdir}, but in a subdirectory.
Are there packaging guidelines for java where such issues are explained?
-- Pat
Le lundi 26 mars 2007 à 20:36 +0200, Patrice Dumas a écrit :
On Mon, Mar 26, 2007 at 10:33:26AM -0700, Anthony Green wrote:
I believe most end up in %{_libdir}.
Aren't jni files dlopened? If it is the case they should not be in %{_libdir}, but in a subdirectory.
Are there packaging guidelines for java where such issues are explained?
Apart from those jpackage and debian wrote, not that I know of
Nicolas Mailhot kirjoitti:
Le lundi 26 mars 2007 à 20:36 +0200, Patrice Dumas a écrit :
On Mon, Mar 26, 2007 at 10:33:26AM -0700, Anthony Green wrote:
I believe most end up in %{_libdir}.
Aren't jni files dlopened? If it is the case they should not be in %{_libdir}, but in a subdirectory.
Are there packaging guidelines for java where such issues are explained?
Apart from those jpackage and debian wrote, not that I know of
http://www.gentoo.org/proj/en/java/java-devel.xml
Regards, Petteri
-- Gentoo Java Project lead
On Mon, Mar 26, 2007 at 08:50:26PM +0200, Nicolas Mailhot wrote:
Le lundi 26 mars 2007 à 20:36 +0200, Patrice Dumas a écrit :
On Mon, Mar 26, 2007 at 10:33:26AM -0700, Anthony Green wrote:
I believe most end up in %{_libdir}.
Aren't jni files dlopened? If it is the case they should not be in %{_libdir}, but in a subdirectory.
Are there packaging guidelines for java where such issues are explained?
Apart from those jpackage and debian wrote, not that I know of
Where are these guidelines?
Do reviewer accept dlopened files to be dumped in %_libdir, or are these legacy packages?
If reviewer accept that for new packages, that deserves a guideline to explicitly disallow such packaging.
-- Pat
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Patrice Dumas wrote:
On Mon, Mar 26, 2007 at 10:33:26AM -0700, Anthony Green wrote:
I believe most end up in %{_libdir}.
Aren't jni files dlopened? If it is the case they should not be in %{_libdir}, but in a subdirectory.
Are there packaging guidelines for java where such issues are explained?
Actually, I think you are right, but traditionally they have been but in %{_libdir}, and *jars* which depend on libraries have gone in %{_jnidir} = %{_libdir}/jni, per the JPackage 1.5 spec.
Is it also a problem having jars (non-binaries) inside %{_libdir}? Then maybe %{_jnidir} should be %{_datadir}/jni then?
I would tend to think that Debian is more correct here:
Libraries: %{_libdir}/jni Jars that dlopen() these libraries: {_libdir}/java
So, JPackage is sort of backwards from Debian, but I am not sure if that jar directory makes sense.
- -- Sincerely,
David Walluck david@zarb.org
Le lundi 26 mars 2007 à 15:04 -0400, David Walluck a écrit :
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Patrice Dumas wrote:
On Mon, Mar 26, 2007 at 10:33:26AM -0700, Anthony Green wrote:
I believe most end up in %{_libdir}.
Aren't jni files dlopened? If it is the case they should not be in %{_libdir}, but in a subdirectory.
Are there packaging guidelines for java where such issues are explained?
Actually, I think you are right, but traditionally they have been but in %{_libdir}, and *jars* which depend on libraries have gone in %{_jnidir} = %{_libdir}/jni, per the JPackage 1.5 spec.
Is it also a problem having jars (non-binaries) inside %{_libdir}? Then maybe %{_jnidir} should be %{_datadir}/jni then?
jni jars are not arch independant so they should be in %{_libdir}/something
I would tend to think that Debian is more correct here:
Libraries: %{_libdir}/jni Jars that dlopen() these libraries: {_libdir}/java
except we already have the jvms there
So, JPackage is sort of backwards from Debian, but I am not sure if that jar directory makes sense.
You could mix library and jar files in {_jnidir}, but it's probably saner to define two distinct roots under %{_libdir}
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Nicolas Mailhot wrote:
jni jars are not arch independant so they should be in %{_libdir}/something
But the jars themselves should be the same on any arch. In this way they are not arch-dependent.
- -- Sincerely,
David Walluck david@zarb.org
Le lundi 26 mars 2007 à 15:42 -0400, David Walluck a écrit :
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Nicolas Mailhot wrote:
jni jars are not arch independant so they should be in %{_libdir}/something
But the jars themselves should be the same on any arch. In this way they are not arch-dependent.
IMHO trying to get the dependencies right on a multilib system will be a nightmare if you try to share the jars (how do you handle the case libs in lib64 but not lib?), and you may have the case when /usr/share is network-mounted on systems with different arches (sparc and x86_64...) so it's not worth the pain. Just make arch-specific packages in arch-specific filesystem-space
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Nicolas Mailhot wrote:
IMHO trying to get the dependencies right on a multilib system will be a nightmare if you try to share the jars (how do you handle the case libs in lib64 but not lib?), and you may have the case when /usr/share is network-mounted on systems with different arches (sparc and x86_64...) so it's not worth the pain. Just make arch-specific packages in arch-specific filesystem-space
I am assuming that jars are arch-independent, meaning the md5sum, say, will be the same across platforms. I don't understand when you say ``you may have the case when /usr/share is network-mounted on systems with different archs''---arch-dependent files don't go in /usr/share in the first place.
Presumably, java.library.path would be set at runtime depending on the arch of the JDK run. The default JDK search patch would probably be to search for the native arch first (still allowing the usual overriding of JAVA_HOME).
- -- Sincerely,
David Walluck david@zarb.org
David Walluck wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Nicolas Mailhot wrote:
IMHO trying to get the dependencies right on a multilib system will be a nightmare if you try to share the jars (how do you handle the case libs in lib64 but not lib?), and you may have the case when /usr/share is network-mounted on systems with different arches (sparc and x86_64...) so it's not worth the pain. Just make arch-specific packages in arch-specific filesystem-space
I am assuming that jars are arch-independent, meaning the md5sum, say, will be the same across platforms. I don't understand when you say ``you may have the case when /usr/share is network-mounted on systems with different archs''---arch-dependent files don't go in /usr/share in the first place.
There's also the case of jar files that bundle arch-dependent compiled code. Andrew, how is that handled in the Fedora Eclipse RPMs?
Tom
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Thomas Fitzsimmons wrote:
There's also the case of jar files that bundle arch-dependent compiled code. Andrew, how is that handled in the Fedora Eclipse RPMs?
I am not sure, but this is what I would do in %{_prefix}/lib/java:
swt-gtk-3.2.2.jar -> ../../../usr/lib64/eclipse/plugins/org.eclipse.swt.gtk.linux.x86_64_3.2.2.v3236.jar swt-gtk-3.2.jar -> swt-gtk-3.2.2.jar
Yes, we can find examples where jars are actually arch-dependent. Come on, they are bundling binary code, so of course they are.
That doesn't mean that they aren't completely wrong in doing so. These libraries should really be unbundled and one swt.jar shared across all archs. A jar bundling binary code? If we allow this, what's next?
- -- Sincerely,
David Walluck david@zarb.org
David Walluck writes:
Yes, we can find examples where jars are actually arch-dependent. Come on, they are bundling binary code, so of course they are.
That doesn't mean that they aren't completely wrong in doing so.
That's really not at issue here. We're talking about where to put the jars from upstream packages, not whether the upstream maintainers are right.
Andrew.
* Thomas Fitzsimmons fitzsim@redhat.com [2007-03-26 16:31]:
There's also the case of jar files that bundle arch-dependent compiled code. Andrew, how is that handled in the Fedora Eclipse RPMs?
They're in %{_libdir}/eclipse.
Andrew
Le lundi 26 mars 2007 à 16:08 -0400, David Walluck a écrit :
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Nicolas Mailhot wrote:
IMHO trying to get the dependencies right on a multilib system will be a nightmare if you try to share the jars (how do you handle the case libs in lib64 but not lib?), and you may have the case when /usr/share is network-mounted on systems with different arches (sparc and x86_64...) so it's not worth the pain. Just make arch-specific packages in arch-specific filesystem-space
I am assuming that jars are arch-independent, meaning the md5sum, say, will be the same across platforms. I don't understand when you say ``you may have the case when /usr/share is network-mounted on systems with different archs''---arch-dependent files don't go in /usr/share in the first place.
Sure. But again jni jars are not arch-independent. They depend on arch-specific binaries to work. How do you ensure the correct arch-dependent binaries are present if you dump the jars in /usr/share/java ? Remember it will expose them to build-classpath and friends. This is different from the usual arch-dependent code use arch-independant situation. In fact it's the reverse situation so you need to do the arch filtering at the jar level.
(I'm tired bow, If I make sense to someone can he reword my explanation?)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Nicolas Mailhot wrote:
Sure. But again jni jars are not arch-independent. They depend on arch-specific binaries to work. How do you ensure the correct arch-dependent binaries are present if you dump the jars in /usr/share/java ? Remember it will expose them to build-classpath and friends. This is different from the usual arch-dependent code use arch-independant situation. In fact it's the reverse situation so you need to do the arch filtering at the jar level.
(I'm tired bow, If I make sense to someone can he reword my explanation?)
Sorry, I am not trying to give you a hard time. I honestly don't get it. If a file is the same across all archs, it is by definition arch-independent. The where to find the library issue seems liek a runtime issue only (but I see also the problem of how to express the correct Requires for rpm.
- -- Sincerely,
David Walluck david@zarb.org
Le lundi 26 mars 2007 à 16:45 -0400, David Walluck a écrit :
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Nicolas Mailhot wrote:
Sure. But again jni jars are not arch-independent. They depend on arch-specific binaries to work. How do you ensure the correct arch-dependent binaries are present if you dump the jars in /usr/share/java ? Remember it will expose them to build-classpath and friends. This is different from the usual arch-dependent code use arch-independant situation. In fact it's the reverse situation so you need to do the arch filtering at the jar level.
(I'm tired bow, If I make sense to someone can he reword my explanation?)
Sorry, I am not trying to give you a hard time. I honestly don't get it. If a file is the same across all archs, it is by definition arch-independent.
My arch-dependency test is a little different : "will it work on any arch". So a shell script that call an arch-specific binary is not arch-independent in my book (unless the arch-specific binary is sure to be present on all supported arches, and that's stretching it)
I don't want to expose useless files to users. Unless you find a way to make sure jni stuff in /usr/share will always have the needed support in /usr/lib*, I'd rather segregate it in arch-dependent parts.
The where to find the library issue seems liek a runtime issue only (but I see also the problem of how to express the correct Requires for rpm.
This is the big one
Regards,
David Walluck writes:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Nicolas Mailhot wrote:
IMHO trying to get the dependencies right on a multilib system will be a nightmare if you try to share the jars (how do you handle the case libs in lib64 but not lib?), and you may have the case when /usr/share is network-mounted on systems with different arches (sparc and x86_64...) so it's not worth the pain. Just make arch-specific packages in arch-specific filesystem-space
I am assuming that jars are arch-independent, meaning the md5sum, say, will be the same across platforms.
That may or may not be true. It is certainly not something you can assume.
Andrew.
Nicolas Mailhot wrote:
I would tend to think that Debian is more correct here:
Libraries: %{_libdir}/jni Jars that dlopen() these libraries: {_libdir}/java
except we already have the jvms there
%{_libdir}/jni is unused and JPackage reserves %{_libdir}/java for arch-specific jars.
Tom
David Walluck wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Patrice Dumas wrote:
On Mon, Mar 26, 2007 at 10:33:26AM -0700, Anthony Green wrote:
I believe most end up in %{_libdir}.
Aren't jni files dlopened? If it is the case they should not be in %{_libdir}, but in a subdirectory.
Are there packaging guidelines for java where such issues are explained?
Actually, I think you are right, but traditionally they have been but in %{_libdir}, and *jars* which depend on libraries have gone in %{_jnidir} = %{_libdir}/jni, per the JPackage 1.5 spec.
Is it also a problem having jars (non-binaries) inside %{_libdir}? Then maybe %{_jnidir} should be %{_datadir}/jni then?
I would tend to think that Debian is more correct here:
Libraries: %{_libdir}/jni Jars that dlopen() these libraries: {_libdir}/java
So, JPackage is sort of backwards from Debian, but I am not sure if that jar directory makes sense.
I would like to implement this in Fedora, but jpackage-utils is not mulitlib-aware. Given that jpackage-utils installs directories in /usr/lib, it would make sense to make it architecture-specific. Currently, we use the simpler approach of hard-coding _libdir to /usr/lib64 in the spec files of 64-bit JDKs and appending .%{_arch} to their JAVA_HOME directories. I haven't done much research into making jpackage-utils multilib (i.e., checked how Debian and Gentoo handle this), but at some point we should probably go back and design jpackage-utils/multilib interaction more thoroughly.
Tom
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Thomas Fitzsimmons wrote:
Thomas Fitzsimmons wrote:
hard-coding _libdir to /usr/lib64
I meant /usr/lib.
Tom
I can't seem to get this right: %_jndir is set to %{_prefix}/lib/java.
- -- Sincerely,
David Walluck david@zarb.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Thomas Fitzsimmons wrote:
I would like to implement this in Fedora, but jpackage-utils is not mulitlib-aware. Given that jpackage-utils installs directories in /usr/lib, it would make sense to make it architecture-specific. Currently, we use the simpler approach of hard-coding _libdir to /usr/lib64 in the spec files of 64-bit JDKs and appending .%{_arch} to their JAVA_HOME directories. I haven't done much research into making jpackage-utils multilib (i.e., checked how Debian and Gentoo handle this), but at some point we should probably go back and design jpackage-utils/multilib interaction more thoroughly.
THen, I guess I should have said %_jndir is %{_prefix}/lib/jni, not %{_libdir}/jni.
But, I guess multilib needs to be fixed, but FHS also needs to be verified for jars which dlopen().
- -- Sincerely,
David Walluck david@zarb.org
Patches cheerfully accepted on jpackage-discuss: https://www.zarb.org/mailman/listinfo/jpackage-discuss Jason
On 3/26/07, Thomas Fitzsimmons fitzsim@redhat.com wrote:
David Walluck wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Patrice Dumas wrote:
On Mon, Mar 26, 2007 at 10:33:26AM -0700, Anthony Green wrote:
I believe most end up in %{_libdir}.
Aren't jni files dlopened? If it is the case they should not be in %{_libdir}, but in a subdirectory.
Are there packaging guidelines for java where such issues are explained?
Actually, I think you are right, but traditionally they have been but in %{_libdir}, and *jars* which depend on libraries have gone in %{_jnidir} = %{_libdir}/jni, per the JPackage 1.5 spec.
Is it also a problem having jars (non-binaries) inside %{_libdir}? Then maybe %{_jnidir} should be %{_datadir}/jni then?
I would tend to think that Debian is more correct here:
Libraries: %{_libdir}/jni Jars that dlopen() these libraries: {_libdir}/java
So, JPackage is sort of backwards from Debian, but I am not sure if that jar directory makes sense.
I would like to implement this in Fedora, but jpackage-utils is not mulitlib-aware. Given that jpackage-utils installs directories in /usr/lib, it would make sense to make it architecture-specific. Currently, we use the simpler approach of hard-coding _libdir to /usr/lib64 in the spec files of 64-bit JDKs and appending .%{_arch} to their JAVA_HOME directories. I haven't done much research into making jpackage-utils multilib (i.e., checked how Debian and Gentoo handle this), but at some point we should probably go back and design jpackage-utils/multilib interaction more thoroughly.
Tom
-- fedora-devel-java-list mailing list fedora-devel-java-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-java-list
java-devel@lists.fedoraproject.org
-
Andrew Haley -
Andrew Overholt -
Anthony Green -
David Walluck -
Jason Corley -
Nicolas Mailhot -
Orion Poplawski -
Patrice Dumas -
Petteri Räty -
Thomas Fitzsimmons