Re: Library handling in squeeze + 1
-----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-----
Reply to: