Dalibor Topic wrote: >> I had in mind a stricter definition that takes semantics into account. >> For example if a method breaks its contract by changing its behaviour >> then it may be a new ABI, even if the method signature is the same. >> > Is it possible to derive such information automatically?
No, that's what makes library packaging so tricky. > If it isn't, I don't see how that would be feasible > without reading and comparing different versions of a package with each > other, I've occasionally done precisely that for C libraries. However responsible upstream developers would document library API/ABI changes in the changelog. If they don't then one must check the code for changes, or manage the risk of introducing bugs. Most of the Debian library packaging guide [1] applies to Java libraries too. It seems to me that this problem has been ignored for Java libs just because Java doesn't automatically force us to deal with it, like SONAMEs do to some extent. Cheers, Marcus [1] http://www.netfort.gr.jp/~dancer/column/libpkg-guide/libpkg-guide.html _______________________________________________ pkg-java-maintainers mailing list [email protected] http://lists.alioth.debian.org/mailman/listinfo/pkg-java-maintainers
