Quoting Marcus Better <marcus@better.se>:
Andrew Haley wrote:In my opinion, Java libraries without stable interfaces shouldn't be deployed in free OSes.That's a nice goal but unfortunately the world is not so perfect, because users occasionally require new software with shiny new bells and whistles. Besides we cannot control upstream and prevent them from breaking ABI. As a distribution we need to find a balance between features and stability. I think the Java policy needs to be tweaked to allow for multiple versions of the same library. The problem is much easier than for C libraries, since we don't have a dynamic linker, so the user is responsible for adding the correct library to the classpath.
I could not agree more. I assume you mean the packager needs to reference the right version of a library.
We just need to make sure the different versions don't conflict, which usually means that both of them cannot install the generic symlink "/usr/share/java/foo.jar".
It seems it would suffice to have the symlink created by postinst, which would point it at the latest installed version (similar to ldconfig).
I actually have a question about that. What do we need the symlink without the version for. It actually looks dangerous to me to have that. An application could use the symlink and then another app gets updated which changes the symlink to a newer version with a different API. That would then actually break the first application.
Why do we actually need the symlink and not just link to the correct version only.
In terms of separating the artifacts i think an option would be to include the package structure and the version into directory structure so e.g. commons-cli could be located in org/apache/commons/cli/0.9 and in parallel have a org/apache/commons/cli/1.0 and so on.
The jars could then be in /usr/share/java/org/apache/commons/cli/0.9. Note that this kind of reproduces the structure in Maven repositories with the advantage that Debian packagers could control that structure (whereas the Maven repo is a big tangled mess).
Note that I'm not suggesting we should package several versions of libraries. That should be avoided, but when necessary there should be a way to do it.
Would it be possible for one package to actually create different versions? Otherwise it would need to be possible to have different versions of the same package installed at the same time without file conflicts (which could be dealt with as suggested above).
manfred