Hello,
Sorry, this is long...
* Jan Schulz <[EMAIL PROTECTED]> wrote:
>>> Just a wrapper for a simple '-ws gtk' and '-ws motif' change?
>> Yes, I think it will be easier to manage it with update-alternatives.
> Thats true. But that will be a maintainance nighmare, if I have to
> change every bit in two or more places, just to have two different
> '-ws' values...
I had some more thoughts about this: How about adding a file to
/usr/share/eclipse, which will be sourced from the starter script.
In that file you would have to specify the name of the -ws option
(gtk, motif, more to come...). This file would then be managed by
update alternatives: every lib, which provides libswt2.1-java would
have to provide one such file and then u-a would set the symlink...
> So apart from the eclipse startscript ('-ws' problem, binary
> launcher) also the library itself has to be under
> update-alternatives...
I'm currently thinking, that I will completly drop the binary
launcher or compile it statically from one -ws. The launcher hast
two usecases: display the splash screen and showing a window with
any occuring error message (which is essentially showing the return
code and the complete call to the JVM). In the moment I don't have
any idea how to show a splash screen (if not by compiling the thing
statically), but the rest can be done in the startscript (which has
anyway most of the functionallity already...). The only drawback
is, that I can't show a error code, if eclipse wasn't started in an
Xterm/Konsole.
> There isn't really a problem: I will use update-alternatives after
> getting the motif thingies working again. The swt.jar will be
> renames to swt-<ws>.jar (no problem with binary libs: they get
> anyway named after the ws, which is used) and update-alternative
> will set the symlink to swt.jar.
Unfortunatelly I found some more things, which I hadn't thought
about: there are more jars in the gtk version of swt, and I'm not
sure how I should handle them... I will ask the the swt ML for
that...
This will also mean, that I will place the 'real' jar files into the
subdir of eclipse, provide symlinks to /usr/share/java under the
name of swt-{ws}.jar and let u-a symlink from there...
> I will rename libswt-java to libswt-gtk2-java and leting it
> provide libswt-java
I'm currently not sure, whether the new virtual package should be
'versioned' like most of the other libraries are: libswt-java or
libswt2.1-java. I had a look at the list of available virtual
packages and it seems that there is no library, which is handled in
this way... So we are a first :)
So, to sum it up (u-a is update-alternatives...):
* Remove the binary launcher ...
- no splash screen
- no error messages, when not started from console
+ faster startup :)
+ no annoying splash screen :)
... Or compile it statically ...
- bigger starter
- inconsistent -ws in some cases
- is it actually policy comform?
+ splash screen
+ error messages even when not started in the console
... or include the starter in libswt-{ws}-java
- logically not the right place
- completly wrong when swt is used without eclipse
+ managable with u-a
* add a small file, which is sourced by the starter script
+ no maintanance nighmare because the main funktionallity is still
in the starter script itself.
- needs to be specified
+ other scripts (if any swt apps show up) can use the same
mechanism
... alternative:
* make the -ws option in $HOME/.eclipse/eclipsrc 'none-optional'
+ no overhead with u-a
- eclipse will not start 'out-of-the-box' in most cases
* put swt.jar and others under u-a
~ symlinks have to be aranged (eclipse subdir ->
/usr/share/java/swt-{ws}.jar -> u-a -> /usr/share/java/swt.jar
+ all installed -ws can be used in eclipse or in any other swt app
(by specifying swt-{ws}.jar instead of swt.jar in the CLASSPATH)
* add a virtual package for the swt library
? which name?
> libswt2.1-java would mean no problems upgrading in a API change.
On the other hand it would mean, that this package could be
installed next to, lets say, libswt3.0-java, which can't be done
with the current filenames (swt.jar needs version info in the
filename, like swt2.1.jar or something...). So either more changes
on that places or just drop the 'version info'...
So, there are still lots of open questions... Can anyone with more
experience comment on this? Should I send all this to debian-devel
ad ask there?
I must say, that this changes look very complicated to me and I'm
wondering, if there are any 'easier' ways to have two versions of
a library...
Can anyone recommend a nice package, which uses update alternative a
lot? Blackdown JDK packages?
As another sidenote: I have eclipse 2.1.1 almost ready (just some
problems with the buildnotes...) and I hope that RC4 will be
released as final version (should have happend on friday already...)
I unziped and tar.gz'ed the source code and got 5MB less for the
orig.tar.gz (10MB with the original zip file...). Cool.
Jan
