> Hm. That sounds strange, but I only see one .deb and that's right. Not sure where and when you looked. I see two packages for every arch on which the build is concluded. https://edge.launchpad.net/ubuntu/karmic/+source/java-gnome Perhaps you looked at it before the new binary packages for cleared from queue.
> Just to be clear, though, to avoid potential future misunderstandings: > The Java (.jar) and C (.so) parts of java-gnome are 100% tightly coupled. > They are not API / ABI compatible between different releases, and there is no > public API on the JNI side. So seeing "separate binary packages" sounds > dangerously like someone is wanting to create two independent binary products > from one source tree, though I only see one .deb which seems correct. > The loading of native code by Java programs being frought with difficulty and > a very common source of nightmare for developers and users. We went to > significant (and quite innovative) lengths to engineer this problem out > entirely. The libjava-gnome-java package depends on libjava-gnome-jni. So there is no chance of use installing the .jar file without .so file. The reason they got split is because it is usual practice. The .jar is architecture independent so it lives in a 'arch:all' package. The .so is dependent on architecture so it lives in a 'arch:any' package. Also I had tried the simple hello world example (from java-gnome website) on Debian before asking the sponsorship. It ran without problem. If there are any more test suites you would like me to run, let me know. >> Remove the hard coded version of jni .so file. > I'm not sure what that meant. I suspect it just meant cleaning up previous > packaging work. Yes. > When I looked, however, I found something called > 01_change_jni_library_location.diff You do not need that patch at all. > Instead, just use the confgure line: > ./configure prefix=/usr jardir=/usr/share/java libdir=/usr/lib/jni > jdk=/usr/lib/jvm/default-java > (based on reading > http://launchpadlibrarian.net/30728086/buildlog_ubuntu-karmic-amd64.java-gnome_4.0.12-1_FULLYBUILT.txt.gz > and https://launchpadlibrarian.net/30722782/java-gnome_4.0.12-1.diff.gz) > where the libdir option gets you what you were trying to do with the patch. > It is, however, *critical* that you use configure to tell the build system > about where the .jar and .so are to end up, because that information is > propegated elsewhere. I had not worked on that patch. I will take a look and drop it if necessary. > Incidentally, Debian, Gentoo and Fedora's requirements have been catered for since the beginning. If you do need something that usptream doesn't do, then upstream will change to accomodate it because it is important to us that the experience using a package and the experience building from source be the same. > That's why libdir= and jardir= overrides are offered to packagers. There is one thing you could change in the build process. The javadoc generation currently fails in build environment. The reason seems to be that the doc generation process tries to take screenshot by launching application (using something called Harmony). This is not possible in the build environment in Debian/Ubuntu. Please let me know if I should file a bug for this. Meanwhile I am working on skipping the screenshot taking part of the javadoc generation. > Oh, from the build log: >> # We don't install this one >> rm -f debian/tmp/usr/lib/libgtkjava-4.0.so > We don't create that file [not since, oh, mid java-gnome 4.0.7? March 2008 at the latest] so no need to remove it :) Hmm. I will remove the code in next upload. > I appreciate all the hard work of the people packaging java-gnome for Ubuntu and Debian. I've met Manu and Guillaume before, of course, but it'd be nice to get to know the others. You're welcome to join us on IRC or via mailing lists. Cheers. I have recently got involved with the package out of personal interest. I will surely join you on IRC. :-) -- New upstream version (4.0.12) https://bugs.launchpad.net/bugs/380446 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
