Re: Debconf Java BOF discussions
On Thu Jul 16 22:42, Torsten Werner wrote: > On Sun, Jul 12, 2009 at 4:47 PM, Matthew Johnson wrote: > > I've arranged for a Debian Java BOF at Debconf this year which I know many > > people won't be at, so I'd like to have some sort of pre-discussion first. > > thanks for organizing the BOF and I will be there. I currently do not > have much time for prediscussion before arriving in Cáceres on next > thursday. Do you want to start an agenda in Debian wiki? I've added an short agenda here: http://wiki.debian.org/Teams/JavaDebconf9 sorry it's not before debconf started, but I didn't have much spare time. matt -- Matthew Johnson signature.asc Description: Digital signature
Re: Debconf Java BOF discussions
Hi Matthew, On Sun, Jul 12, 2009 at 4:47 PM, Matthew Johnson wrote: > I've arranged for a Debian Java BOF at Debconf this year which I know many > people won't be at, so I'd like to have some sort of pre-discussion first. thanks for organizing the BOF and I will be there. I currently do not have much time for prediscussion before arriving in Cáceres on next thursday. Do you want to start an agenda in Debian wiki? Cheers, Torsten -- To UNSUBSCRIBE, email to debian-java-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Debconf Java BOF discussions
Matthew Johnson wrote: > I've arranged for a Debian Java BOF at Debconf this year which I know many > people won't be at, so I'd like to have some sort of pre-discussion first. > > There are a number of issues I'd like to try and sort out with packaging > policy, and actually try and get them baked into policy. Firstly, I think we > need to move most of the changes suggested at FOSDEM 2006[1] into the main > policy. I then have some large issues and a couple of small ones which I'd > like > to address. > > General issues: > >- FOSDEM Draft >- Packaging tools >- Jar dependency resolution >- Transitions > > FOSDEM Draft: > > Library changes look good, particularly dropping runtime dependencies. Javadoc > is all sensible. Native and arch-dependent stuff is also all sensible. Unit > tests, shouldn't specifically refer to JUnit, but I think if the maintainer is > happy that there aren't any racy tests, failing the build on a failing unit > test is entirely reasonable. If it's a real regression, you really do want to > fail the build. > > The virual package section from here has been superseded since and I think we > have a fairly sensible set of packages. > > Packaging tools: Project Jigsaw is going to change Java packaging in a major way. Whatever Debian changes to do, it needs to be able to work with the Jigsaw system. http://openjdk.java.net/projects/jigsaw/ Andrew. -- To UNSUBSCRIBE, email to debian-java-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Debconf Java BOF discussions
On Sun Jul 12 21:37, Johan Henriksson wrote: > > I think we should mandate one of the standardised ways of doing dependency > > resolution so that in most cases application writers don't need to maintain > > recursive classpaths; java -jar should work and therefore jarwrapper can be > > used to avoid writing any wrapper at all (In fact, -jar doesn't work at all > > without a Class-Path attribute as -cp is ignored, so we can't make use of > > the > > Main-Class attribute either). It would also allow jh_depends to generate the > > correct dependencies. > > > is there a sane way of handling JNI? in particular directories in > addition to /usr/lib/jni , for picky libraries you don't want to modify > all too much. Hmm, I think things really should be in /usr/lib/jni, particularly if: > packaging would be easier if we mandated that all JREs include > /usr/lib/jni by default in the search path for libraries. AFAIK this is > not the case now. or if we want to play nice with binary-only > proprietary JREs, a jh_install that symlinks in > /somestrangeJREdirectoryForJNI/. just an idea. If it's not the case now then I think we should make the all include that by default (although jarwrapper, for example, makes sure it's on $LD_LIBRARY_PATH anyway). Playing nice with things outside main is always optional. > >- Currently the rest of 2.3 says that programs must have all the classes > > in > > /usr/share/java. Programs which aren't expecting their classes to be > > used > > as a library can surely ships jars in /usr/share/$program ? > > if there is an advantage for programs, then why should they get special > treatment? surely any helper programs should be able to list > recursively? if upstream builds multiple jars then it might be best to > keep them separated. symlinking for versions would be done on the > directory in that case, not the contents. Well, any jar which you expect someone to put on their classpath should be in /usr/share/java. Hence, libraries. If a library has a separate jar which should not be included directly, but picked up via a Class-Path: directive, that doesn't necessarily need to be in /usr/share/java, but it's a less common use case imo. > given that openjdk probably becomes the most used JRE once 7 is out, > would it make sense to try and improve the manifest with version > numbering etc upstream? it might get java programmers to add this > information for us, reducing the amount of work on our end. Yes, once we decide on what we are doing, pushing it upstream is always useful. Matt -- Matthew Johnson signature.asc Description: Digital signature
Re: Debconf Java BOF discussions
> I think we should mandate one of the standardised ways of doing dependency > resolution so that in most cases application writers don't need to maintain > recursive classpaths; java -jar should work and therefore jarwrapper can be > used to avoid writing any wrapper at all (In fact, -jar doesn't work at all > without a Class-Path attribute as -cp is ignored, so we can't make use of the > Main-Class attribute either). It would also allow jh_depends to generate the > correct dependencies. > is there a sane way of handling JNI? in particular directories in addition to /usr/lib/jni , for picky libraries you don't want to modify all too much. packaging would be easier if we mandated that all JREs include /usr/lib/jni by default in the search path for libraries. AFAIK this is not the case now. or if we want to play nice with binary-only proprietary JREs, a jh_install that symlinks in /somestrangeJREdirectoryForJNI/. just an idea. > >- Currently the rest of 2.3 says that programs must have all the classes in > /usr/share/java. Programs which aren't expecting their classes to be used > as a library can surely ships jars in /usr/share/$program ? > if there is an advantage for programs, then why should they get special treatment? surely any helper programs should be able to list recursively? if upstream builds multiple jars then it might be best to keep them separated. symlinking for versions would be done on the directory in that case, not the contents. given that openjdk probably becomes the most used JRE once 7 is out, would it make sense to try and improve the manifest with version numbering etc upstream? it might get java programmers to add this information for us, reducing the amount of work on our end. /Johan -- -- Johan Henriksson MSc Engineering PhD student, Karolinska Institutet http://mahogny.areta.org http://www.endrov.net -- To UNSUBSCRIBE, email to debian-java-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Debconf Java BOF discussions
Dear Debian Java packagers, I've arranged for a Debian Java BOF at Debconf this year which I know many people won't be at, so I'd like to have some sort of pre-discussion first. There are a number of issues I'd like to try and sort out with packaging policy, and actually try and get them baked into policy. Firstly, I think we need to move most of the changes suggested at FOSDEM 2006[1] into the main policy. I then have some large issues and a couple of small ones which I'd like to address. General issues: - FOSDEM Draft - Packaging tools - Jar dependency resolution - Transitions FOSDEM Draft: Library changes look good, particularly dropping runtime dependencies. Javadoc is all sensible. Native and arch-dependent stuff is also all sensible. Unit tests, shouldn't specifically refer to JUnit, but I think if the maintainer is happy that there aren't any racy tests, failing the build on a failing unit test is entirely reasonable. If it's a real regression, you really do want to fail the build. The virual package section from here has been superseded since and I think we have a fairly sensible set of packages. Packaging tools: I've been trying to fill out as many useful tools as possible in javatools [2] (javahelper/jarwrapper) to make it as simple as possible to package java programs, including a CDBS class for them all. I'd love suggestions for more tools or improvements to these. jh_depends - turns a Class-Path manifest into Depends, also adds depends on jarwrapper, VMs and virtual packages as appropriate. jh_manifest - an easy way to update manifest files of the built jars. jh_exec - any jars which are (linked to) the PATH are made executable jh_build - very simple build system for jars jh_installlibs - for installing jars to /usr/share/java with the correct names and links jh_makepkg - builds a template debian/ dir for a java program/library including cleaning up common things from upstream. java-propose-classpath - uses javap to find jars that it should be depending on. Not automatable though due to a. optional depends and b. multiple jars with overlapping contents. jarwrapper - uses binfmt-misc to run executable jar files. Jar dependency resolution: At the moment all programs need to know recursively all the jars which they will use. This introduces unnecessary transitions when a library changes it's dependencies, more work for packagers writing wrappers scripts, and long classpath lines in them. Java already has a method for recursively generating classpaths with the Class-Path: manifest entry and there are similar things with Eclipse's OSI manifest extensions[3], whereas Gentoo use separate gentoo-specific config files which are used for generating wrappers. I think we should mandate one of the standardised ways of doing dependency resolution so that in most cases application writers don't need to maintain recursive classpaths; java -jar should work and therefore jarwrapper can be used to avoid writing any wrapper at all (In fact, -jar doesn't work at all without a Class-Path attribute as -cp is ignored, so we can't make use of the Main-Class attribute either). It would also allow jh_depends to generate the correct dependencies. It may also be worth considering manifest extensions to do with class file versions, so that when virtual packages are determined by jh_depends it can recursively use class file versions to determine the minimum JVM version required for running the program. At the moment it checks all the class files in that package to generate the alternatives list. Transitions: I've mentioned the class-path issues relating to transitions. In general, however, we don't have a good plan for transitions. I recently had to update one of my packages in a rush because it FTBFS with the new version of a library which didn't change package name. Now, we mandate that packages ship jars with version-number-based file names, but because the packages aren't co-installable, this isn't very useful. I think we need to change to something more like the way C libraries use sonames: - the numbering in the filename should also be in the package - it should be bumped for non-backwards-compatible changes - possibly the symlink should be in some sort of dev package (with the javadoc?) The javahelper tools can then resolve those symlinks to the correct filename / package depends. Specific (minor) issues: - As #395372, Java policy should not restrict executables to /usr/bin, but to anywhere which policy would normally allow - #227594 suggests removing the section about binfmt_misc and class files. I agree with this; using binfmt_misc for class files is a bad idea. Only trivial applications are sing
