I'm not sure why it goes into /opt (that decision predates my tenure), but
since the JRE is included it may be considered a large software package
unsuitable for the /usr directory, and since it is an add-on application
software packages opt seems to be a sensible place. It may also be a solaris
thing that leaked into the thought process. These packages also were designed
to be launched from within a desktop shell, so being on the path was less of an
issue.
For 8u40 and earlier it is in fact hard coded in the generation of the
supporting files for RPM and DEBs. Based on my reading that could be made
configurable, at least at time of packaging. If you submitted a JIRA we could
get that in for 8u60, but the new feature/new bug window for 8u40 is mostly
closed. However the structure underneath the package is a larger item to mess
around with, so it would merely be a pointer to a different directory to
install it in as opposed to placing bits widely across the system.
Perhaps a step in the package that adds a link to /usr/bin in the control file
or install scripts may be a better solution.
On Jan 27, 2015, at 1:29 PM, Mike Hearn m...@plan99.net wrote:
javapackager makes debs that install things into /opt, which means they
aren't on the path. Is there a reason for this choice rather than making
FHS-compliant packages that install into /usr?
thanks!
