> > 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.
