Re: Symbols/shlibs files for Java
(+cc: debian-java; please cc me on replies if following up there)
Hi Niels,
Niels Thykier wrote:
> we can still gain a lot
> from automated ABI/API breakage detection and well defined transitions[1].
This means allowing Java packages to use ${shlibs:Depends} in the same
way packages with binaries do? Sounds excellent.
> [1] Such being able to tell if reverse dependencies have been rebuilt
> against the new version of a library or not.
I had thought that Java doesn't require this in the way that DSOs do
(but I could easily be wrong; see below [*]). According to my
assumptions, either there is an API break or no ABI break at all; in
the former case, this means serious (FTBFS) bugs, while in the latter
case it is nice to rebuild the reverse dependencies in case they run a
test suite to catch problems but it does not need to affect
transitions to testing.
Example: Suppose I rename some important function or method. This
would be analogous to renaming a function in C, which warrants a
soname bump. So in C, there would be two versions of the DSO, one
from before and one after:
libexample.so.1 (in an old libexample1 binary package)
libexample.so.2 (in a new libexample2 binary package)
Before the updated libexample can transition to testing, we need all
packages that used to link to the former to start linking to the
latter, even if they never use the renamed function.
Now on the other hand suppose I decide to add a new function. This
is also a change in ABI, but it is backward-compatible, so it does not
warrant a soname bump. The deb-symbols infrastructure means we can
automatically add versioned dependencies based on functions an
application uses (which is great[**]), but it doesn't enter into
transition tracking much --- there is no need to rebuild packages
before the new version of the library enters testing.
C++ works the same way because constructors, destructors, overloaded
functions, and so on are implemented as functions with mangled names
behind the scenes.
In Java, though, I had thought that there was nothing like a soname
bump when a function gets removed.
[*] I mentioned above that I am probably missing something. :) It
might be possible to achieve something like the
libexample1/libexample2 case above by installing two versions of a
Java package, setting the classpath appropriately at run-time. If
there is something similar in common use, that's probably the big
piece I was confused about.
[**] This is the part that seems exciting to me for Java.
> As it is now, we manually create a libXY-java package if we suspect
> that the new version of libX-java is not backwards compatible.
Could you give an example? Does this also change the API or only ABI?
> First of all I was hoping that you might have some "Do" or "Don't"
> pointers from when dpkg added support for these things. Secondly, there
> might be some code or infrastructure that could be shared.
> Particularly I am interested in how you handle mapping
> filenames/SONAMES to a package (especially in cases like libc6, where
> there more than one lib in the package).
See deb-shlibs(5) and deb-symbols(5). (I know you already have. Just
listing references for future readers.)
> We also have cases where two packages provide the same library and it
> would be optimal for us to end up with libX-java | libY-java in the
> depends, but I have a feeling that is not entirely trivial to support
> (in a sane way).
The symbols file supports this. It should be possible as long as
the build-deps of packages using these libraries have enough
information to figure it out (so, it can't be "libX-java and libY-java
install files to the same directory and javahelper figures it out").
> I am not too sure that we can recycle the existing formats
> (maybe the shlibs format with s/SONAME/filename/) as we have to check
> for things like classes, return-types, inheritance and method
> overloading as well.
I think checking for ABI breakage is a different and harder problem.
The symbols infrastructure can notice if a symbol was added or
removed, but in C and C++ that is not enough to know if something
(like the return type, as you mention) changed.
Have you talked to the authors of the "ABI compliance checker" at
<http://ispras.linux-foundation.org/index.php/ABI_compliance_checker>?
Thanks and good luck,
Jonathan
Reply to: