FS#27991 - [jdk7-openjdk] Install Shared Objects (SO) in /usr/lib

Attached to Project: Arch Linux
Opened by Hugo Osvaldo Barrera (hobarrera) - Thursday, 19 January 2012, 06:46 GMT
Last edited by Andreas Radke (AndyRTR) - Saturday, 03 March 2012, 15:12 GMT
Task Type Bug Report
Category Packages: Extra
Status Closed
Assigned To Andreas Radke (AndyRTR)
Guillaume ALAUX (galaux)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 1
Private No

Details

Description:

Libraries (Shared Objects) for jdk7-openjdk are installed into /usr/lib/jvm/java-7-openjdk/jre/lib/amd64/.

Having them in /usr/lib would be far more practical; currently, when running a java application that requires one of these SO, one needs to export LD_LIBRARY_PATH=/usr/lib/jvm/java-7-openjdk/jre/lib/amd64 first. Having them in /usr/lib would avoid this.

/usr/lib is also there for exactly these sort of files; the is no reason to create a lib directory inside /usr/lib/jvm/java-7-openjdk/jre/ and move these libraries there.

Fixing this would make running java applications a tiny bit easier, and also keep the filesystem a bit tidier.
This task depends upon

Closed by  Andreas Radke (AndyRTR)
Saturday, 03 March 2012, 15:12 GMT
Reason for closing:  Won't fix
Additional comments about closing:  such major change would need to be done upstream.
Comment by Andrew Gaydenko (student975) - Thursday, 19 January 2012, 07:17 GMT
Even for manually installed jdk there isn't any need to export LD_LIBRARY_PATH explicitly to run java application: it is sufficient just to add $JAVA_HOME/bin to $PATH.
Comment by Hugo Osvaldo Barrera (hobarrera) - Thursday, 19 January 2012, 07:58 GMT
It is for SOME applications, specifically, those that use libs in that location, or libs that depend on one of those.
The first example that comes to mind is minecraft, and some other applications that load their own SO, which, in turn, depend on the ones mentioned here.
Comment by Andrew Gaydenko (student975) - Thursday, 19 January 2012, 08:20 GMT
@hobarrera,

You don't take into account this use case: a system can have few different installed JDKs. A common way is to supply needed JAVA_HOME in (or for) startup applications' scripts. These scripts are who must accomplish all needed work basing on JAVA_HOME.
Comment by Hugo Osvaldo Barrera (hobarrera) - Thursday, 19 January 2012, 10:45 GMT
Generally, if a user wants to use a java application he'll use "java -jar file.jar", not make a script to run it.

Just as several JDKs can be installed at the same time, the same can happen with any other package containing a file in /usr/lib. The same is also true for other applications (I can have two versions of python installed, but only one will be /usr/bin/python).
That's really no excuse for _not_ having one as default.


Comment by Andrew Gaydenko (student975) - Thursday, 19 January 2012, 11:29 GMT
There are plenty opportunities to install this or that software. As for jre/jdk - there are traditions and, as a result, developers' expectations jre/jdk distribution are located the way they are during years. If you want to complicate java developers' life you will invent own way to install jre/jdk :-)
Comment by Hugo Osvaldo Barrera (hobarrera) - Thursday, 19 January 2012, 11:56 GMT
So this is just "tradition" instead of simplicity? What about KISS?

I'm not trying to complicate thing, on the contrary, I want to make things easier to run.
The average doesn't know that he needs to export LD_LIBRARY_PATH in order to run random app/game he just downloaded. I actually had a hard time finding the info myself when I downloaded minecraft and a couple of other games, and I'm a java developer.
Comment by Andrew Gaydenko (student975) - Thursday, 19 January 2012, 12:08 GMT
As for KISS:

1. At this case expectation is a KISS.
2. At this case uniform approach to all installed jdk/jre is a KISS.

You are trying to make things easier for the only application. I'm strongly sure it is more appropriate to make this application to fit reality.

I'm also a java developer starting from java 1.2, and I expect more problems in your approach rather at current state.
Comment by Hugo Osvaldo Barrera (hobarrera) - Thursday, 19 January 2012, 12:36 GMT
I don't thing most user have more than one JDK installed. I don't think most developers do either.
It's not ONE application, it's several (all games, for sure).

Game developers can't guess where to search for these files/start creating scripts for every os/distro. Heck, most work fine out-of-the-box in mac or even windows by just double clicking them. But here, we keep *SOME* libs on a separate directory for "tradition", and the game just can't guess where they are.
Comment by Andrew Gaydenko (student975) - Thursday, 19 January 2012, 13:00 GMT
Again, it is common practice to use JAVA_HOME. If some app doesn't or can't, it is the app's problem. At any case it is a law to have default jdk/jre distribution structure under JAVA_HOME.
Comment by Hugo Osvaldo Barrera (hobarrera) - Thursday, 19 January 2012, 19:39 GMT
Generally, java applications targeted at end-users are distributed as a single cross-platform jar file meant to be "double clicked" and just run. My goal was simply to add this level of simplicity to arch, since JAVA_HOME is unset by default, and most users won't know how to tailor a script to run these themselves.

But, if "tradition" and the ability to have several JDKs installed is more important, I guess you can close this bug.
Comment by Andrew Gaydenko (student975) - Thursday, 19 January 2012, 20:03 GMT
Hugo, I was hoped it is clear "tradition" here is an expectation of plenty of programs in their using of known distribution structure plus basing on JAVA_HOME value.

Probably another way is closer to golden compromise: jdk installation script can set JAVA_HOME.
Comment by Hugo Osvaldo Barrera (hobarrera) - Thursday, 19 January 2012, 20:50 GMT
This still requires users to write a script using JAVA_HOME as a reference, it makes very little differente in the long run.
On the other hand, it may make life easier for packagers, since THEY could write scripts that use this value to make them JRE-agnostic.
Comment by Andreas Radke (AndyRTR) - Monday, 20 February 2012, 08:44 GMT
I tend to not implement this. It's not needed for any of our own binary packages. It's not an upstream standard to add symlinks for the libs or install directly to /usr/lib. And we would be on our own when things break as no other distribution seems to do what you suggest.

So if there's no further strong argument why it would be really needed I will close this with "won't implement". If you think it should be done for all distributions ask upstream on the
distro-pkg-dev@openjdk.java.net mailing list.

Loading...