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!
