Re: The evils of /usr/share/java/repository

[Ben Burton <bburton@mail.math.okstate.edu>]

> > Does anyone have reasons why /usr/share/java/repository should remain?
>
> No do do not like that repository. Can we have some consensus about this?
>
> Should I remove it from the policy?

Can we also remove the bullet point under "Advice to Java Packagers" that
*recommends* using the repository instead of jars?

> Just one though. The symlink. Should that be automaticly generated
> by a tool that are runned from the postinst script or should it
> be provided by the (latest, or most compatible) version of the package?

The way this is done in /usr/lib is that the symlink is provided by
package libfoo-dev and you can only ever have one such package installed.
This makes no sense for java because the development files are precisely
the same as the library itself (i.e. lib-foo-java.jar).

So if the debian packages provide the links themselves then it would seem
you can only ever have one version of lib-foo-java.jar installed at any
given time, which seems undesirable (and defeats the point of installing
lib-foo-java-version.jar).

So I guess this leaves the postinst script.  My first thought would be to
have a tool, say javaconfig, which you run like:

javaconfig /usr/share/java/lib-editline-java.jar

And it searches for all files called
/usr/share/java/lib-editline-java-*.jar, compares the versions (pieces
in the place of *) using a sensible comparison (like debian versions, not
strict lexicographical) and creates a link to the highest version.

If there is no such jar, it deletes the link lib-editline-java.jar (if it
exists).  This means you can call javaconfig in the postinst and in the
postrm, and the link will always be created, updated or removed as
necessary.

Does this sound right?

Ben.