Le samedi 02 janvier 2010 à 15:47 +0100, Alexander Boström a écrit :
Removed this text:
The <code>%{_jnidir</code>} rpm macro defines the main JNI jar repository. Like <code>%{_javadir</code>} it is declined in <code>-ext</code> and <code>-x.y.z</code> variants. It follows exactly the same rules as the <code>%{_javadir</code>}-derived tree structure, except that it hosts JAR files that use JNI. <code>%{_jnidir</code>} usually expands into <code>/usr/lib/java</code>.
It seems to belong to the "The plan is to eventually..." part, but I don't really understand it. Explain and I'll add something back. :)
When the original JJP guidelines were written people were using lots of different JVMs and app writers were releasing code that only worked on specific java versions, so the original JPP directory structure has always allowed versionned directories where packagers could put jars that only worked on specific versions.
If you look at the shell code macro that resolves filenames in jpackages-utils, you'll see it does something like the following when looking for jar "foo"
1. check the java version the current jvm reports (for example x.y.z) 2. look for "foo.jar" in %{_jnidir}-x.y.z/ 3. look for "foo.jar" in %{_jnidir}-x.y/ 4. look for "foo.jar" in %{_jnidir}-x/ 5. look for "foo.jar" in %{_jnidir}/ 6. look for "foo.jar" in %{_javadir}-x.y.z/ 7. look for "foo.jar" in %{_javadir}-x.y/ 8. look for "foo.jar" in %{_javadir}-x/ 9. look for "foo.jar" in %{_javadir}/
That allowed nifty things like having a single tomcat package (+ deps) that worked both with java-1.3 and java-1.4 jvms, depending on the jvm installed on system (or even with multiple jvms installed and env var changes), at a time when users where split between boths, and creating separate 1.3 and 1.4 packaging stacks would not have been possible for lack of manpower (90% of the components where the same with 1.3 and 1.4, the few exceptions were a PITA to manage)
People tend to put all their jars in %{_javadir}/ nowadays, but the infra is still there to allow multiple versions if needed.
BTW: this part of jpackage-utils was written in a week-end and was intended as a short-term simple brutal implementation while better people created better mechanisms. Better didn't happen years later :(