-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2010-08-06 18:53, Matthew Johnson wrote: > One of the other things we discussed at DebConf 10 is the handling of Java > libraries. For the benefit of those not at DebConf here are the problems and > conclusions we reached (it's long, but there are some questions at the end). > > Leaving aside the problem of detecting when upstream break ABI compatibility > without telling us (for which we also discussed this), there are a number of > problems around handling this which we don't currently answer. > > - if an ABI is added to and a package using the new ABI is built against it, > the dependency can still be satisfied by an older package without that ABI. > > - if an ABI is changed incompatibly it can satisfy the dependency for a > package which used the old ABI. > > - We have no way of doing coordinated transitions - if a library changes, all > it's r-depends must be immediately fixed. > > The second (related) problem is to do with recursively loading classpaths: > > - If library A depends on library B, currently any application depending on A > must include B in its classpath. > > The solution for all this is to change our handling of libraries as follows: > > - Library packages must include the ABI version in the package name, so the > source package will be called foo0, the binary package will be called > libfoo0-java etc. > > - Libraries must install jars as $name-X.Y.Z.jar (package/upstream version) > > - Libraries must install a symlink $name-A.jar (where A is the ABI version) > > - Libraries must conditionally install a symlink $name.jar if they are the > highest abi version installed on the system (this must be done in postinst, > so that multiple packages with different ABIs can be coinstalled) > > - ABI versions may be taken from part of the upstream version or may be > assigned internally by Debian > > - Libraries must list all their non-optional dependencies in the Manifest > classpath (this corresponds to packages which appear in Depends and do not > appear in the Depends of the library's r-depends) > > When building against a library you must: > > - build-depend on the package including the abi version (libfoo0-java) > > - use the symlink without a version in your build classpath unless you > specifically want the older ABI version > > - use the symlink with the ABI version but not the full upstream version > in your runtime classpath > > - depend on the library package including the abi version with the dependency > versionned to be >= the version built against or (if this can be calculated) > an earlier version which is known to work > > This will have the following effects: > > - multiple packages with different ABIs can be installed simultaneously in > order to ease transitions, or support a release with both ABIs > > - rdepends of such packages will depend on and use the correct jar > > - packages will only have their depends satisfied by a version with a > compatible ABI > > - programs don't need to recursively enumerate classpaths, just list their > immediate dependencies > > - a library adding a dependency does not cause all its r-depends to > transition > > - if a library only makes backwards-compatible changes everything will Just > Work (tm) > > - if a library ABI changes in a backwards-incompatible change you must: > > - change the source and binary package names (requiring a trip through > NEW), > - build-r-depends which work with the new ABI just need the dependency > updated to the new version, but no upstream source or build system > changes, > - build-r-depends which _don't_ work with the new version will obviously > need fixing > - rdepends will continue being installable and working with the old ABI > until the transition is complete > - when all rdepends have moved to the new ABI the old source package > needs > to be removed from the archive > > In order to make this easier, a lot of it can be supported by tooling: > > - installation of the symlinks will be done by jh_installlibs (with the ABI > version inferred from the package name) > > - the conditional symlinks will be handled by a prerm/postinst snippet which > will be automatically generated by javahelper > > - references to foo.jar in manifest files will be rewritten to be foo-A.jar > by > jh_manifest > > - classpaths can be added to non-compliant jars with jh_classpath or > jh_manifest > > - jh_depends will populate your Depends: list including minimum version > numbers > > - javahelper will provide a method to do replacement of the classpath > elements > in wrapper scripts at build time so that they point to the correct symlink > for > that ABI. > > I shall write the bits of these which are missing and start staging them via > experimental until squeeze is released. This will mean that essentially all > Java packages must use javahelper, but I think it's a good idea to do so > anyway. > > There has also been some discussion of providing symbols files similar to C > libraries which could be used to detect unannounced ABI changes from upstream > and to relax the version in dependencies. Some work needs to be done to see > how > feasible that is. > > A question which just occurs to me is: should we encode the ABI in the jar > somehow? Possibly a manifest entry? Are there any other manifest entries we > should be adding? > > Please follow up in case that I've missed anything here, or you have any > questions. > > Matt
I just realised that a likely side effect of implementing this idea is that we can no longer allow programs to ship jar files in /usr/share/java and instead these must be moved to a separate library package (or moved to /usr/share/$pkg). ~Niels -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEAREIAAYFAkxjqK0ACgkQVCqoiq1Ylqym2QCaAqui2H3bjSwWjLq1DlRH+6OP LhUAn2J1bxMuXUGiQrSw1P7cHOy0y8Tl =TgZp -----END PGP SIGNATURE----- -- To UNSUBSCRIBE, email to debian-java-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4c63a8ae.2000...@thykier.net
