Re: [PROPOSAL] 3. RfD on new debian java policy
Hallo Dalibor,
First of all, I will apologise for some of my heated 'answer round'
during the last days. I still can't aggre completly with your (and
others) objections, but I see that nothing won't change your opinion
either :) so I try to find a *working* compromise.
I'm currently learning for a exam, so don't expect some bigger 'answer
round' or a updated proposal during the next two days. I'll be back on
friday evening or the weekend...
* Dalibor Topic wrote:
>Great, then if you've tested it you can make your package depend on IBM's java
>and Sun;s java as well and make the lifes of those users who prefer to use
>IBM's or Sun's java easier. Where is the problem?
The problem is, that IBM Java isn't packaged and so you can't
'Depends:' or 'Conflicts:' on it. Thats why I wanted the virtual
packages, so that this is specified as the 'name to use'
As I see, that you (you as in 'you and others' :) won't accept a
virtual package for *all* the 'sun derived' JVM, I try a different
approach: Give IBM, BD and SUN '*-bin' downloads a specific name. This
could be done by asking the mpkg-j2sdk author to make the package
names vendor specific and something more official (a.k.a "somwhere
wriiten down" and "not chnaging ever other build"). Maybe it would
even be possible to include it more tightly with java-common.
This will mean, that 'java*-runtime', 'java-virtual-machine',
java*-compiler will become completly useless, as all package would
'Depends:' on the tested packages and not on the unspecific 'virtual
package'.
The 'for users only' alternatives for 'java', 'javac' and 'javadoc'
could ("...may..") still be created (with one default value).
I will also try to implement a prototype of the 'findjava' skript.
Usage as follows:
* will 'echo' the full name to a 'java binary' pluss some VM args, so
should be used like
|JAVCMD=`findjava <options>`
This will give you the posebility to react to this choice (like
adding some jar to the CP or giving VM specific switches). The VM
args will be specified by the user or by the packager and will
include mostly things to tune some internal behaviour (IBM java and
eclipse is better with some JIT specific switches)
* <OPTIONS> will be include a list of packagenames (much like
'java-config''), which are tested and found able to run the package.
* findjava will return the 'java binary' and the options based on:
o 'force overwrite' option of the user
o one of the specified java binaries (specified by package name),
based on:
. User specified preferences, if the users preference is include
in the list.
. some other preferneces given by other options
. order of the list.
o exit 1 in case no 'java binary' can be found
* other options as I find some use for them, like --server or --client
VM, which will automagically choose a 'able' VM before a 'unable'
and includes this args for the VM, if 'able'.
Any others?
The required config files (package to 'java binary' and 'VMargs',
something for 'server' and 'client' and other things) will be handled
by the same system as java-config files.
This all will mean that some parts of the current proposal will be
still almost the same:
* the 'ant environment' specification is still intact, only the
'unfree interface' will be split into more packages, one for each
'unfree VM'. I hope this will be possible to with mpkg-j2sdk. I only
would like to include the bootclasspath here, as it would make the
'jikes-something' adapter unessesary.
* The java-config' interface is still the same.
* Browser Plugin will be the only alternative protected by a virtual
package. Anyone disagree?
Comments?
So, now my only question is still: what will be the agreed upon
reaction to me filling bugs about 'include ibm-java (version) in your
dependency, as it works'? I'm not happy (still) if I have to download
more packages than nessesary and I would like to know what are the
options for me, if a packager will just say 'its unfree, I will not
include it'.
Comments?
Jan
--
Jan Schulz jasc@gmx.net
"Wer nicht fragt, bleibt dumm."
Reply to: