Marcus Better wrote: > Paul Cager wrote: >> E.g. the POM could require JUnit-3.8.1 but Debian has packaged version >> 3.8.2. In this case we would set up a link in the temporary Maven >> repository: >> >> debian/.m2/repository/.../junit-3.8.1.jar -> /usr/share/java/junit.jar >> -> /usr/share/java/junit-3.8.2.jar > >> We should check that the Debian version is not *older* than the version >> required by the POM, but we are still relying on releases being backwards >> compatible. Any comments? > > This is a recipe for disaster since the dependencies will likely break ABI > at some point. Then our package will FTBFS if we are lucky, or build and > run with the wrong version and give very interesting bugs later on. (On the > other hand it's similar to what we already do...) > > It seems to me that we must keep track of ABI compatibility. This is a bit > complicated, but it's our job if we want to be a well-integrated > distribution. In other words we should try to solve the library versioning > problem first, and only then try to build packages with Maven.
There are two sides to that: ABI compatibility tells us if class A will continue to link to class B. It does not tell us anything about classes using reflection, for example. So it's not a substitute for rebuilding and rerunning the test suite, just a quick way of confirming that a combination of classes would cause trouble. I think the stricter criterium (builds & runs tests successfully) is sufficient, and does not require maintaining ABI information. cheers, dalibor topic _______________________________________________ pkg-java-maintainers mailing list [email protected] http://lists.alioth.debian.org/mailman/listinfo/pkg-java-maintainers
