Wouter van Reeven schrieb:
[...]
> One possible solution would be to make sure commands are used that are the same
> on ALL platforms. One implementation could be to use Java to do all install
> related commands. However, people use KDE, Gnome, Windows, etc so to what level
> should the installer be generalized?
Well from a pragmatic point of view I see two solutions here:
(a) As, asides the Unix .sh installer, there's always the option of using
the .zip package, the most straightforward way would be to simply state "not
supported on platform XY" if the installer is not likely to work with
platform XY. If you intend to install glassfish on a headless Unix server,
say, using ssh + X11 forwarding, you will be required to have at the very
least a few basic X11 libraries installed to have this work anyhow, so
chances are you want to go for the zip installer here if you know about that
in advance. :)
(b) Make it portable to the degree required by the installation. I.e.
whether using GNOME, KDE, CDE or (in my case...) XFCE on Unix doesn't matter
much while talking about the Unix .sh installer. Using Linux, Windows,
Solaris, ... doesn't matter much given a .jar based installer, in example
(except for the display thing explained earlier, of course...).
(c) Introduce fallbacks for "simple"(?) basic traps like this. Using mktemp
would work well without any arguments after all, as a fallback... or even
mkdir if anything else fails. IMHO this seems an issue too trivial to make
the installation bail out without doing anything. :)
Any way, leaving it broken on a couple of systems without an explicit hint
or explanation doesn't seem to be a good solution. I'm tempted to file an
issue but I'd like to see others opinions first...
Cheers,
Kristian
--
Kristian Rink
cell : +49 176 2447 2771
business: http://www.planconnect.de
personal: http://pictorial.zimmer428.net
"we command the system. calling all recievers.
we are noisy people for a better living".
(covenant - "monochrome")