[icedtea-web] RFC: add javaws and itweb-settings to jre/bin as well

Omair Majid omajid at redhat.com
Tue Dec 14 09:32:33 PST 2010

On 12/14/2010 10:39 AM, Dr Andrew John Hughes wrote:
>>>> One thing that I did notice is that 'make install' will install over
>>>> existing files but adding ln -s makes this fail. Should I guard ln -s
>>>> with a check to ensure that the symlink does not exist? Should I rm the
>>>> symlink location first? Or is there a better thing to do in such cases?
>>> Do we actually need them? Could we not just fix javaws to use $(bindir)?
>>> I'm not keen on having this non-standard directory (as regards the normal
>>> /usr layout, not the JDK).
>> My concern is more towards what users expect. If users expect a javaws
>> binary under JDK_HOME/jre/bin/ as well as JDK_HOME/bin, then not having
>> it might cause issues.
>> As for fixing javaws, can I hardcode JDK_HOME/bin/javaws for now, or
>> should I make it use $(bindir) from configure?
> It should use $(bindir).  It's perfectly possible someone could install in /usr
> and /usr/jre/bin is going to look quite odd.  As such, I'd suggest only creating
> the symlinks if $(prefix)/jre/bin exists.

Does the attached patch look ok? It only creates or removes links if 
jre/bin exists. The javaws launcher now sets a system propert 
java.javaws.bindir which is set to the bindir where javaws is installed. 
Netx then does System.getProperty("java.javaws.bindir") + "/javaws" to 
build the path to itself.

The launcher already sets the property "application.home" to point to 
the bindir , but it uses some logic that seems inappropriate for the 
general case - it chops off strings like bin/ from the end of the 
executable path :/

I dont see why/how anyone would install into a prefix that does not 
already contain a JDK. I tried out installing to a prefix without an 
existing /jre/ (i.e. installing to anything other than a jdk) and it 
makes javaws fail on start up. Currently the error is :
./javaws: error while loading shared libraries: libjli.so: cannot open 
shared object file: No such file or directory
But I suppose that even if libjli was found, it would fail complaining 
that it cannot find a VM.

>>> If we really really do, then they need to be created with a guard as you suggest.
>>> I can't see an install option for links.
>> What if the links exist but could be invalid? I would rather do
>> something like
>> rm -f old_link
>> ln -s new_bin new_link
>> Does that look ok?
> You also check that old_link is a link and not a regular file.  test -L.
> So something like:
> if [ -e $(prefix)/jre/bin ] ; then
>    if [ -L $(prefix)/jre/bin/javaws ] ; then
>      rm -f $(prefix)/jre/bin/javaws ;
>    fi
>    if [ ! -e $(prefix)/jre/bin/javaws ] ; then
>      ln -s $(bindir)/javaws $(prefix)/jre/bin ;
>    fi ;
> fi
> and similar cases for the others.

Thanks for the snippet!

>> Right, but again this may cause issues if users expect 'jcontrol' to
>> work. That said, I personally have no problems with this.
> I think it will be more confusing, to be honest, to have a different tool with the
> same name.  I know we have 'javaws' but doing it with the control panel too seems
> to go a bit far.

Alright. I dont expect any problems either - we didnt have it at all 
before and we didnt get any complaints then.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: add-binaries-to-jre-bin-03.patch
Type: text/x-patch
Size: 3312 bytes
Desc: not available
Url : http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20101214/75b7a925/add-binaries-to-jre-bin-03.patch 

More information about the distro-pkg-dev mailing list