/usr/share/java as maven repository?

Dalibor Topic robilad at kaffe.org
Fri Dec 28 00:49:48 UTC 2007


Marcus Better wrote:
> Dalibor Topic wrote:
>   
>>> 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.
>>     
>
> 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? 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, which, at least for something
like Eclipse, is a tall order on any packager due to the sheer size of
the source code.
>> I think the stricter criterium (builds & runs tests successfully) is
>> sufficient, and does not require maintaining ABI information.
>>     
>
> Then we cannot prevent a library from being upgraded to an incompatible
> version, as in the Tomcat breakage that was reported to the list just the
> other day. That should prove that we do need ABI information.
>   
In theory, uploading the package that broke Tomcat could have triggered
a series of rebuilds of
packages depending on it, along with their test suites, and chances are
it would have been caught
that way.

I have to admit that I must have missed an explanation of what was wrong
with tomcat 5.5 and
commons-io in detail other than it required an older version, so it's
not clear to me whether that
is a binary compatibility requirement mismatch that could have been
caught by a tomcat5.5
rebuild, or something else.
> Also there are packages that don't have test suites, or that don't run them
> at build time.
>   
Assuming one rebuilds the world sitting on top of the uploaded package
with the uploaded
package installed as a 'QA' measure, there is a very good chance to
catch ABI breakage
that way (i.e. binary compatibility issues preventing rebuilds of
packages depending on
the updated package, and resulting in fun linkage exceptions at runtime).

Incompatible semantic changes could be caught by the package's own test
suite, or by one of
the test suites of packages depending on it. If they aren't, well,
that's what bugs.debian.org is
for. ;) It'd be great if more packages ran their test suites as part of
the build process, it would
give us more confidence that we we're shipping works sufficiently well
for the configuration
it is built for.

I don't think we can catch all possible issues that way (i.e. rebuild
reverse-deps with updated
package before upload and run their test suites), but it could both make
having explicit ABI
information unnecessary (as build errors would be triggered by the
rebuild), and reduce
'version drift' issues by catching them as soon as they are about to be
introduced.

How we deal with version drift issues, by patching a package using the
drifting one if it's a one
line change, or introducing different versions of it into the archives,
is something that I assume
the packagers decide on a case by case basis.

cheers,
dalibor topic




More information about the pkg-java-maintainers mailing list