Re: [PROPOSAL] 3. RfD on new debian java policy
Hallo Dalibor,
* Dalibor Topic wrote:
>I don't know how much of the VM options can be safely specified in such an
>interface. I guess the easiest way is to add a switch -J<some vm specific
>option> that passes the option to the VM without specifying anything about the
>options the VM understands.
More or les it will be done like this:
The app asks for a 'server' VM. The findjava script will find one, and
it requires that the vmarg '-server' is required.
so 'findjava --server VM1 VM2 VM3_server_able'
will return
/patt/to/VM3_server_able -server
If a VM sees fit, other options may be allied automaically like
switching on the jitter in all cases.
>> '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.
>I don't think requiring in the ant environment bootclasspath is desirable, as
>it requires a java 1.3+ VM, and a lot of code that uses ant to build can build
>on a lower VM and doesn't need to mess with the bootclasspath. I'd prefer to
>treat eclipse as an exception, not as a rule in this case ;)
Its not for teh bootclasspath of the VM but for the the compiler to
find the 'bootclasses'. Have a look at the 'jikes-something' wrapper
scripts. Ant generally uses eitehr he specified bootclasspath to
compile the classes or the bootclasspath of the running VM.
>I don't think you could force a maintainer to include a VM in his
>package list, as you can't force packagers to trust people ('so it
>works, eh? did you run the regression tests? can I have the result
>files?'), but the policy should encourage the packagers to work with
>their users and the upstream to provide support for as many VM
>enviroments as possible, through relying on co-maintainers, and
>knowledgeable users to handle those VM environments they have no
>access to.
I will include the wording of one of the other mails, which goes in
this direction. A maintainer has to include all 'tested and working
VM', but more or less its the maintainers descision to choose what
'tested enough' means.
It will mean that Ic an file bugreports about this, so I'm happy :)
>Of course, this depends how strictly defined the
>co-maintainer status is, i.e. can you be a co-maintainer/test dude
>without being a debian developer?
Yes, of course. I'm not a DD and I maintaine eclipse through Takshi
Okamoto, who sponsors me until I'm finished with my NM application.
Only a DD can upload packages to teh debian archiv, so this must be
either done via one of the maintainer or by a sponsor.
Jan, fed up with learning and having a break :)
--
Jan Schulz jasc@gmx.net
"Wer nicht fragt, bleibt dumm."
Reply to: