Re: guava-libraries 18?
Le 27/10/2014 16:07, Hilko Bengen a écrit :
> 1. Testing whether a rebuild against the newer version still works is
> clearly not sufficient: code can be loaded at run-time, for instance.
True, but that's more the exception than the rule, and I don't think
many projects load Guava classes dynamically.
http://codesearch.debian.net/search?q=Class.forName\%28%22com.google.common
> 2. I wouldn't know what to check beyond that simple rebuild.
Building the reverse dependencies and running the test cases is the best
we can reasonably do.
> 3. We (Debian) already know how to deal with ABI breakage in shared
> libraries produced from (mostly) C and C++ code: Change the SONAME
> (upstream's job) and adjust the name of the resulting library package
> accordingly.
I'm not familiar enough with shared C/C++ libraries to compare, but I'd
like to highlight that in Java you can't have two incompatible versions
of the same library on the classpath. So if elasticsearch pulls another
library that depends on guava but is incompatible with the version 18,
it's likely to break at runtime.
> In the short run, this increases the number of packages in the
> distribution, but different versions of a given library can co-exist.
With some care to the Maven artifacts though. The package with a fixed
version must not install Maven artifacts with the generic 'debian'
version, otherwise it would conflict with the main versionless package.
Also it should not install Maven artifacts with the exact version
either, as it would prevent the main package from being upgraded to this
same version.
So for the guava-libraries-18 package, a solution would be to install
Maven artifacts with the version '18.x' only.
> This generally saves work because checking a potentially large number of
> reverse dependencies is not needed right away and needs to be done only
> when the old version is removed.
I'd argue that this may also create some work to transition the reverse
dependencies. They have to be updated one by one to depend on the more
recent package. I've done that for ASM, CGLIB and the Servlet API,
that's not exactly a fun task :)
> Why can't we do the same for Java libraries where upstream authors in
> general seem much less willing to watch out for API/ABI compatibility?
Well we can and we do when it's necessary, but I think we should
evaluate if this is necessary first. For example ASM used to break the
compatibility on every new major release, but it got better with the
version 5 and we have been able to upgrade the libasm4-java package
directly instead of creating a new package and triggering a transition.
> 4. I don't really care about most of the packages that may or may not
> break with the changed API/ABI in guava-18.
I rebuilt the 26 reverse dependencies of Guava with the version 18 and I
got only two failures with gradle and closure-compiler. They both failed
due to the removal of ByteStreams.newInputStreamSupplier(byte[]) and
Files.newReaderSupplier(File, Charset). So adding back these two methods
is all that's really needed to transition to the new version.
Emmanuel Bourg
Reply to: