--- Jan Schulz <[EMAIL PROTECTED]> wrote:
> Hallo Dalibor,
>
> * Dalibor Topic wrote:
> >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
>
--- Jan Schulz <[EMAIL PROTECTED]> wrote:
> Hallo Dalibor,
>
> * Dalibor Topic wrote:
> >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
>
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 -Joption> that passes the option to the VM without specifying anything about the
>options the VM understands.
More or les it wil
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 -Joption> that passes the option to the VM without specifying anything about the
>options the VM understands.
More or les it wil
Hallo Jan,
--- Jan Schulz <[EMAIL PROTECTED]> wrote:
> 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
Hallo Jan,
--- Jan Schulz <[EMAIL PROTECTED]> wrote:
> 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
Hallo Dalibor,
* Dalibor Topic wrote:
>> Maybe the policy could say "A package must (should?) depend on the
>> disjunction of all JVMs with which it has been tested succesfully". That
>> does not force the packager to use any non-free program, but gives
>> strength to bug reports to include ano
Hallo Dalibor,
* Dalibor Topic wrote:
>> Maybe the policy could say "A package must (should?) depend on the
>> disjunction of all JVMs with which it has been tested succesfully". That
>> does not force the packager to use any non-free program, but gives
>> strength to bug reports to include ano
Salut Daniel,
--- Daniel Bonniot <[EMAIL PROTECTED]> wrote:
> Isn't it fine if another person testifies that the package works with
> this-or-that JVM? I suppose this already happens with specific
> architectures or hardware.
> So if a package works with a JVM not in its depends, one can file a
Salut Daniel,
--- Daniel Bonniot <[EMAIL PROTECTED]> wrote:
> Isn't it fine if another person testifies that the package works with
> this-or-that JVM? I suppose this already happens with specific
> architectures or hardware.
> So if a package works with a JVM not in its depends, one can file a
I will neither propose nor agree with a debian java policy, which will
ignore this facts and make out users patch debian packages to get this
working.
I don't see the point of making a policy that says that packages must
work with some non-packaged non-free programs. It would be nice if t
> What about an environment variable? Like
> $ someapp
> # runs someapp with one of the packagers tested JVM
> $ JAVA=/usr/bin/kaffe someapp
> # runs with kaffe
This works for me (and indeed it's what I've done with the jython
package).
> Is there is a risk of JAVA being already in use for some
A better way in my opinion is to allow the user to 'override' maintainer's
choice of VM environment in some easy way (like putting another java executable
in front of his path, or running a selectmyvm script).
I agree this is a good solution: the default behaviour is going to work
because the mai
I will neither propose nor agree with a debian java policy, which will
ignore this facts and make out users patch debian packages to get this
working.
I don't see the point of making a policy that says that packages must
work with some non-packaged non-free programs. It would be nice if t
> What about an environment variable? Like
> $ someapp
> # runs someapp with one of the packagers tested JVM
> $ JAVA=/usr/bin/kaffe someapp
> # runs with kaffe
This works for me (and indeed it's what I've done with the jython
package).
> Is there is a risk of JAVA being already in use for some
A better way in my opinion is to allow the user to 'override' maintainer's
choice of VM environment in some easy way (like putting another java executable
in front of his path, or running a selectmyvm script).
I agree this is a good solution: the default behaviour is going to work
because the mai
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
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
Hallo Jan,
--- Jan Schulz <[EMAIL PROTECTED]> wrote:
> Hallo Dalibor,
>
> * Dalibor Topic wrote:
> >> I don't do it. I just see the need, that some people will want to run
> >> java apps on a unfree VM. This propsal makes this possible.
> >But it is already possible, isn't it?
>
> Yes, because t
Hallo Jan,
--- Jan Schulz <[EMAIL PROTECTED]> wrote:
> Hallo Dalibor,
>
> * Dalibor Topic wrote:
> [kdelibs4 problems]
> >> all cases to '1', but the latest qt version in unstable is '2'. I don't
> >> think that anyone bothers to test their packages, when one of the
> >> dependencies changed.
> >
Hallo Jan,
--- Jan Schulz <[EMAIL PROTECTED]> wrote:
> Hallo Dalibor,
>
> * Dalibor Topic wrote:
> >> I don't do it. I just see the need, that some people will want to run
> >> java apps on a unfree VM. This propsal makes this possible.
> >But it is already possible, isn't it?
>
> Yes, because t
Hallo Jan,
--- Jan Schulz <[EMAIL PROTECTED]> wrote:
> Hallo Dalibor,
>
> * Dalibor Topic wrote:
> [kdelibs4 problems]
> >> all cases to '1', but the latest qt version in unstable is '2'. I don't
> >> think that anyone bothers to test their packages, when one of the
> >> dependencies changed.
> >
--- Ben Burton <[EMAIL PROTECTED]> wrote:
>
> > >I'm quite happy with this suggestion as well (must -> may for non-free
> > >JVM dependencies). If at least one of the dependencies is satisfied
> > >- even if this is selected from a list of only free JVMs - then the
> > >app will presumably run s
--- Ben Burton <[EMAIL PROTECTED]> wrote:
>
> > >I'm quite happy with this suggestion as well (must -> may for non-free
> > >JVM dependencies). If at least one of the dependencies is satisfied
> > >- even if this is selected from a list of only free JVMs - then the
> > >app will presumably run s
> So what? I just compiled kdelibs4, to get the -dev package working
> with experimental Xfree4.3 (xlibs-pic -> xlibs-static-pic). It took me
> half a day (yes, that was my first such compile problem...) to figure
> out, why it didn't configure on my newly installed unstable. Until I
> saw how the
> >I'm quite happy with this suggestion as well (must -> may for non-free
> >JVM dependencies). If at least one of the dependencies is satisfied
> >- even if this is selected from a list of only free JVMs - then the
> >app will presumably run successfully and so there's no problem if
> >non-free
Hallo Mark,
* Mark Wielaard wrote:
>I am afraid we are not communicating very constructively.
>We might have to start from scratch since somehow we keep missing each
>others points.
Seems so. To sum it up:
* I want to have the possibility to use unfree VMs with java packages
* you don't want to i
Hi,
I am afraid we are not communicating very constructively.
We might have to start from scratch since somehow we keep missing each
others points. Let me try one last time to point out what I find
important facts when deciding how to create a java policy for Debian.
On Mon, 2003-09-08 at 20:15,
> So what? I just compiled kdelibs4, to get the -dev package working
> with experimental Xfree4.3 (xlibs-pic -> xlibs-static-pic). It took me
> half a day (yes, that was my first such compile problem...) to figure
> out, why it didn't configure on my newly installed unstable. Until I
> saw how the
> >I'm quite happy with this suggestion as well (must -> may for non-free
> >JVM dependencies). If at least one of the dependencies is satisfied
> >- even if this is selected from a list of only free JVMs - then the
> >app will presumably run successfully and so there's no problem if
> >non-free
Hallo Mark,
* Mark Wielaard wrote:
>I am afraid we are not communicating very constructively.
>We might have to start from scratch since somehow we keep missing each
>others points.
Seems so. To sum it up:
* I want to have the possibility to use unfree VMs with java packages
* you don't want to i
Hi,
I am afraid we are not communicating very constructively.
We might have to start from scratch since somehow we keep missing each
others points. Let me try one last time to point out what I find
important facts when deciding how to create a java policy for Debian.
On Mon, 2003-09-08 at 20:15,
Hallo Ben,
* Ben Burton wrote:
>> this 'let's make free software in debian depend on non-free software'
>> proposal is incompatible with debian's goal, afaik. turn that into a
>> 'may depend on the unfree interfaces ' and I'll be happier with it.
>I'm quite happy with this suggestion as well (must
Hallo Dalibor,
* Dalibor Topic wrote:
>> I don't do it. I just see the need, that some people will want to run
>> java apps on a unfree VM. This propsal makes this possible.
>But it is already possible, isn't it?
Yes, because the curent proposal makes nor difference between free and
unfree ones.
Hallo Dalibor,
* Dalibor Topic wrote:
[kdelibs4 problems]
>> all cases to '1', but the latest qt version in unstable is '2'. I don't
>> think that anyone bothers to test their packages, when one of the
>> dependencies changed.
>Whoever changed the dependency should have tested the packages that de
Hallo Mark,
* Mark Wielaard wrote:
>On Sun, 2003-09-07 at 13:31, Jan Schulz wrote:
>I would call it byte code interpreter then.
>Try to avoid the java name a bit since Sun claims a trademark on it.
>And it make it more clear that it is only one part of the environment
>that people might want. (The
Hallo Jan,
--- Jan Schulz <[EMAIL PROTECTED]> wrote:
> Hallo Ben,
>
> * Ben Burton wrote:
> >Yes, but in the old policy it's clear that we don't really know what
> >works and what doesn't. In the new proposal, we claim to specify
> >precisely which VMs work with which package, and so if we encou
Hallo Ben,
* Ben Burton wrote:
>> this 'let's make free software in debian depend on non-free software'
>> proposal is incompatible with debian's goal, afaik. turn that into a
>> 'may depend on the unfree interfaces ' and I'll be happier with it.
>I'm quite happy with this suggestion as well (must
Hallo Dalibor,
* Dalibor Topic wrote:
>> I don't do it. I just see the need, that some people will want to run
>> java apps on a unfree VM. This propsal makes this possible.
>But it is already possible, isn't it?
Yes, because the curent proposal makes nor difference between free and
unfree ones.
Hallo Dalibor,
* Dalibor Topic wrote:
[kdelibs4 problems]
>> all cases to '1', but the latest qt version in unstable is '2'. I don't
>> think that anyone bothers to test their packages, when one of the
>> dependencies changed.
>Whoever changed the dependency should have tested the packages that de
Hallo Mark,
* Mark Wielaard wrote:
>On Sun, 2003-09-07 at 13:31, Jan Schulz wrote:
>I would call it byte code interpreter then.
>Try to avoid the java name a bit since Sun claims a trademark on it.
>And it make it more clear that it is only one part of the environment
>that people might want. (The
Hallo Stefan,
* Stefan Gybas wrote:
>Your proposal is a complete rewrite of the Java Policy but I think this
>step is too big: You have changed a lot of requirements that have been
>discussed in the past but there has not been a consesus. For example,
>you have changed the naming of library JAR
Hallo Ben,
* Ben Burton wrote:
>> >I'm not really comfortable with the idea of "don't test, just assume it
>> >works until someone tells you otherwise". Yes, it happened with flex
>> >but that was a once-off. With this java proposal it will become
>> >institutionalised.
>> It is already instituti
Hallo Jan,
--- Jan Schulz <[EMAIL PROTECTED]> wrote:
> Hallo Ben,
>
> * Ben Burton wrote:
> >Yes, but in the old policy it's clear that we don't really know what
> >works and what doesn't. In the new proposal, we claim to specify
> >precisely which VMs work with which package, and so if we encou
Hi Jan,
On Sun, 2003-09-07 at 13:31, Jan Schulz wrote:
> Do you have a better name for 'programm, which runs java byte code'?
> for me 'java' stands for exactly this and I don't midn if it is
> actually called /usr/bin/kaffe or /usr/lib/sunjdk/bin/java
I would call it byte code interpreter then.
Hallo Stefan,
* Stefan Gybas wrote:
>Your proposal is a complete rewrite of the Java Policy but I think this
>step is too big: You have changed a lot of requirements that have been
>discussed in the past but there has not been a consesus. For example,
>you have changed the naming of library JAR
Hallo Ben,
* Ben Burton wrote:
>> >I'm not really comfortable with the idea of "don't test, just assume it
>> >works until someone tells you otherwise". Yes, it happened with flex
>> >but that was a once-off. With this java proposal it will become
>> >institutionalised.
>> It is already instituti
--- Jan Schulz <[EMAIL PROTECTED]> wrote:
> Hallo Mark,
>
>
> * Mark Wielaard wrote:
> >On Sat, 2003-09-06 at 22:26, Jan Schulz wrote:
> >> The problem in debian is to find out this java.
> >> This should be adressed in this proposal.
> >Why this fixation on this one program name?
>
> Do you ha
Jan Schulz wrote:
This is a significant rewrite of my previous proposal. To make
discussion alittle easier, I've broken the subject line to tell, that
this is the third request for discussion.
Sorry, I've been away a couple of days when you have posted your
proposal so I still need to catch up. I'
Hi Jan,
On Sun, 2003-09-07 at 13:31, Jan Schulz wrote:
> Do you have a better name for 'programm, which runs java byte code'?
> for me 'java' stands for exactly this and I don't midn if it is
> actually called /usr/bin/kaffe or /usr/lib/sunjdk/bin/java
I would call it byte code interpreter then.
--- Jan Schulz <[EMAIL PROTECTED]> wrote:
> Hallo Mark,
>
>
> * Mark Wielaard wrote:
> >On Sat, 2003-09-06 at 22:26, Jan Schulz wrote:
> >> The problem in debian is to find out this java.
> >> This should be adressed in this proposal.
> >Why this fixation on this one program name?
>
> Do you ha
Jan Schulz wrote:
This is a significant rewrite of my previous proposal. To make
discussion alittle easier, I've broken the subject line to tell, that
this is the third request for discussion.
Sorry, I've been away a couple of days when you have posted your
proposal so I still need to catch up. I
> BTW, what tool did you use?
apt-cache showpkg java-virtual-machine
(and look in the Reverse Depends section).
Note that this pulls in Recommends: j-v-m and Suggests: j-v-m as well,
which is presumably why my search picked up more packages than yours. In
particular my search picks up a number
> > Programs must depend on the needed runtime environments, including
> > working versions if the bin/java unfree interfaces.
>
> bzzt! ;)
>
> this 'let's make free software in debian depend on non-free software'
> proposal is incompatible with debian's goal, afaik. turn that into a
> 'may dep
Hallo Jan,
--- Jan Schulz <[EMAIL PROTECTED]> wrote:
> * unfree interfaces are now 'additional to' the normal (free) debian
> packages, which provide a certain functionality
good.
> * java compilers are now use via ant, via an 'ant environment' or must
> be referenced directly (i.e. you nee
Hi Mark,
--- Mark Wielaard <[EMAIL PROTECTED]> wrote:
>
> > [..] ANT_BUILD_COMPILER with the short-name or the full qualified
> > classname of the java compiler [..]
> >
> > Also, for the default environemt, it needs to include the tools.jar.
>
> Yuck. What does this tools.jar provide?
nothin
Hallo Jan,
--- Jan Schulz <[EMAIL PROTECTED]> wrote:
> >I think it would be a good idea to set some sort of policy for this. See
> >e.g. the two different gjdoc packages (gjdoc and gjdoc-native). Why have
> >the gjdoc version that depends on byte code when there is already a
> >normal native appl
Hallo Ben,
* Ben Burton wrote:
>> Currently almost every java app is in contrib: eclipse, tomcat, ant.
>Running a quick check, there are 48 packages that depend on
>java-virtual-machine (which from policy I thus assume to be java apps or
>libs).
BTW, what tool did you use?
>28 in contrib;
>2 in
> BTW, what tool did you use?
apt-cache showpkg java-virtual-machine
(and look in the Reverse Depends section).
Note that this pulls in Recommends: j-v-m and Suggests: j-v-m as well,
which is presumably why my search picked up more packages than yours. In
particular my search picks up a number
> > Programs must depend on the needed runtime environments, including
> > working versions if the bin/java unfree interfaces.
>
> bzzt! ;)
>
> this 'let's make free software in debian depend on non-free software'
> proposal is incompatible with debian's goal, afaik. turn that into a
> 'may dep
> Currently almost every java app is in contrib: eclipse, tomcat, ant.
Running a quick check, there are 48 packages that depend on
java-virtual-machine (which from policy I thus assume to be java apps or
libs).
28 in contrib;
2 in non-free;
18 in main.
That's only about 60% in contrib, certainl
> >I'm not really comfortable with the idea of "don't test, just assume it
> >works until someone tells you otherwise". Yes, it happened with flex
> >but that was a once-off. With this java proposal it will become
> >institutionalised.
>
> It is already institutionalised.
> ...
Yes, but in the
Hallo Jan,
--- Jan Schulz <[EMAIL PROTECTED]> wrote:
> * unfree interfaces are now 'additional to' the normal (free) debian
> packages, which provide a certain functionality
good.
> * java compilers are now use via ant, via an 'ant environment' or must
> be referenced directly (i.e. you nee
Hi Mark,
--- Mark Wielaard <[EMAIL PROTECTED]> wrote:
>
> > [..] ANT_BUILD_COMPILER with the short-name or the full qualified
> > classname of the java compiler [..]
> >
> > Also, for the default environemt, it needs to include the tools.jar.
>
> Yuck. What does this tools.jar provide?
nothin
Hallo Jan,
--- Jan Schulz <[EMAIL PROTECTED]> wrote:
> >I think it would be a good idea to set some sort of policy for this. See
> >e.g. the two different gjdoc packages (gjdoc and gjdoc-native). Why have
> >the gjdoc version that depends on byte code when there is already a
> >normal native appl
Hallo Ben,
* Ben Burton wrote:
>> Currently almost every java app is in contrib: eclipse, tomcat, ant.
>Running a quick check, there are 48 packages that depend on
>java-virtual-machine (which from policy I thus assume to be java apps or
>libs).
BTW, what tool did you use?
>28 in contrib;
>2 in
> Currently almost every java app is in contrib: eclipse, tomcat, ant.
Running a quick check, there are 48 packages that depend on
java-virtual-machine (which from policy I thus assume to be java apps or
libs).
28 in contrib;
2 in non-free;
18 in main.
That's only about 60% in contrib, certainl
> >I'm not really comfortable with the idea of "don't test, just assume it
> >works until someone tells you otherwise". Yes, it happened with flex
> >but that was a once-off. With this java proposal it will become
> >institutionalised.
>
> It is already institutionalised.
> ...
Yes, but in the
Hallo Mark,
* Mark Wielaard wrote:
>On Sat, 2003-09-06 at 22:26, Jan Schulz wrote:
>> The problem in debian is to find out this java.
>> This should be adressed in this proposal.
>Why this fixation on this one program name?
Do you have a better name for 'programm, which runs java byte code'?
for
Hallo Ben,
* Ben Burton wrote:
>> |You must depend on all working java virtual maschines and search all
>> |this packages for the java virtual maschine binary.
>Yes.
Included...
>> I thought that this was fairly obvious... I mean, it's pretty stupit
>> if not :)
>There are lots of things in debi
Hallo Ben,
* Ben Burton wrote:
>> >> 2.2. Java Development Tools
>> >Ant is used by some packages, but why mandate that ant must be used?
>FWIW, this "should use ant" directive occurs in two places. Once in
>section 2.7 (which you said earlier that you'd changed and which I
>suspect is the if/el
--- Mark Wielaard <[EMAIL PROTECTED]> wrote:
> > I have no idea, how far you've looked into the current implemntation
> > to make this possible, so I just give you some of my impressions, from
> > packaging eclipse.
> > * Eclipse wasn't yet able to run with free JVM (kaffee 1.1.1 might
> > chan
Hallo Mark,
* Mark Wielaard wrote:
>On Sat, 2003-09-06 at 22:26, Jan Schulz wrote:
>> The problem in debian is to find out this java.
>> This should be adressed in this proposal.
>Why this fixation on this one program name?
Do you have a better name for 'programm, which runs java byte code'?
for
Hallo Ben,
* Ben Burton wrote:
>> |You must depend on all working java virtual maschines and search all
>> |this packages for the java virtual maschine binary.
>Yes.
Included...
>> I thought that this was fairly obvious... I mean, it's pretty stupit
>> if not :)
>There are lots of things in debi
Hallo Ben,
* Ben Burton wrote:
>> >> 2.2. Java Development Tools
>> >Ant is used by some packages, but why mandate that ant must be used?
>FWIW, this "should use ant" directive occurs in two places. Once in
>section 2.7 (which you said earlier that you'd changed and which I
>suspect is the if/el
--- Mark Wielaard <[EMAIL PROTECTED]> wrote:
> > I have no idea, how far you've looked into the current implemntation
> > to make this possible, so I just give you some of my impressions, from
> > packaging eclipse.
> > * Eclipse wasn't yet able to run with free JVM (kaffee 1.1.1 might
> > chan
> You mean something like
>
> |You must depend on all working java virtual maschines and search all
> |this packages for the java virtual maschine binary.
Yes.
> I thought that this was fairly obvious... I mean, it's pretty stupit
> if not :)
There are lots of things in debian policy that are
> Searching /lib and /usr/lib is what gcj does by default. Should this be
> disabled to comply with the policy?
Policy only requires that /usr/lib/jni be added to the search path.
Whatever else you put there (e.g., /usr/lib, etc. for compatibility with
other distributions) is up to you.
Ben. :)
> >> 2.2. Java Development Tools
> [..]
> >Ant is used by some packages, but why mandate that ant must be used?
>
> Is now changed to 'If package uses ant, then it must... \n If not, ...'
FWIW, this "should use ant" directive occurs in two places. Once in
section 2.7 (which you said earlier tha
> You mean something like
>
> |You must depend on all working java virtual maschines and search all
> |this packages for the java virtual maschine binary.
Yes.
> I thought that this was fairly obvious... I mean, it's pretty stupit
> if not :)
There are lots of things in debian policy that are
Hi Jan,
On Sat, 2003-09-06 at 22:26, Jan Schulz wrote:
> The problem in debian is to find out this java.
> This should be adressed in this proposal.
Why this fixation on this one program name?
I know there is a non-free environment called java that is a
interpreter, byte code definition, class l
> Searching /lib and /usr/lib is what gcj does by default. Should this be
> disabled to comply with the policy?
Policy only requires that /usr/lib/jni be added to the search path.
Whatever else you put there (e.g., /usr/lib, etc. for compatibility with
other distributions) is up to you.
Ben. :)
> >> 2.2. Java Development Tools
> [..]
> >Ant is used by some packages, but why mandate that ant must be used?
>
> Is now changed to 'If package uses ant, then it must... \n If not, ...'
FWIW, this "should use ant" directive occurs in two places. Once in
section 2.7 (which you said earlier tha
Hallo Mark,
* Mark Wielaard wrote:
>On Sat, 2003-09-06 at 19:15, Jan Schulz wrote:
>> * Mark Wielaard wrote:
>> This would mean, that the resulting package will not use 'java' to
>> start the programm and it would be a normal ELF binary, for which all
>> teh rules from the debian policy apply.
>'
Hi Jan,
On Sat, 2003-09-06 at 22:26, Jan Schulz wrote:
> The problem in debian is to find out this java.
> This should be adressed in this proposal.
Why this fixation on this one program name?
I know there is a non-free environment called java that is a
interpreter, byte code definition, class l
Hi,
On Sat, 2003-09-06 at 19:15, Jan Schulz wrote:
> * Mark Wielaard wrote:
> >I am one of the GNU Classpath developers but not a Debian developer.
>
> Thanks for joining anyway :)
I am a Debian user though and use it for all my development machines.
> >For end-user programs I think it would be
Hallo Mark,
* Mark Wielaard wrote:
>On Sat, 2003-09-06 at 19:15, Jan Schulz wrote:
>> * Mark Wielaard wrote:
>> This would mean, that the resulting package will not use 'java' to
>> start the programm and it would be a normal ELF binary, for which all
>> teh rules from the debian policy apply.
>'
Hallo Mark,
* Mark Wielaard wrote:
>I am one of the GNU Classpath developers but not a Debian developer.
Thanks for joining anyway :)
>For end-user programs I think it would be a good idea to mention that
>gcj can be used to compile programs written in the java language into
>normal native binar
Hallo Ben,
* Ben Burton wrote:
>> Java libraries must depend on the needed working runtime
>> environments, including the virtual package names of working
>> versions of the "unfree" bin/java interface.
>If you're going to mandate that developers keep a list of working JVMs
>for their dependencies
Hi,
On Sat, 2003-09-06 at 19:15, Jan Schulz wrote:
> * Mark Wielaard wrote:
> >I am one of the GNU Classpath developers but not a Debian developer.
>
> Thanks for joining anyway :)
I am a Debian user though and use it for all my development machines.
> >For end-user programs I think it would be
Hallo Mark,
* Mark Wielaard wrote:
>I am one of the GNU Classpath developers but not a Debian developer.
Thanks for joining anyway :)
>For end-user programs I think it would be a good idea to mention that
>gcj can be used to compile programs written in the java language into
>normal native binar
Hallo Ben,
* Ben Burton wrote:
>> Java libraries must depend on the needed working runtime
>> environments, including the virtual package names of working
>> versions of the "unfree" bin/java interface.
>If you're going to mandate that developers keep a list of working JVMs
>for their dependencies
> Are there any other requirements? Should /lib and /usr/lib be searched
> or not for example?
The reason for the /usr/lib/jni addition to policy was to get JNI
modules out of /usr/lib directly (since they're dlopened modules, not
"normal" application libraries).
In particular, java policy also
Hi,
I am one of the GNU Classpath developers but not a Debian developer.
On Sat, 2003-09-06 at 01:47, Jan Schulz wrote:
> Chapter 2. Policy
>
> Packages written in Java are separated in two categories: programs
> and libraries. Programs are intended to be run by end-users.
> Libraries are intend
Hi. Just a few more notes on this.
> Java libraries must depend on the needed working runtime
> environments, including the virtual package names of working
> versions of the "unfree" bin/java interface.
(and a similar clause for java programs)
If you're going to mandate that developers keep a
> Are there any other requirements? Should /lib and /usr/lib be searched
> or not for example?
The reason for the /usr/lib/jni addition to policy was to get JNI
modules out of /usr/lib directly (since they're dlopened modules, not
"normal" application libraries).
In particular, java policy also
Hi,
I am one of the GNU Classpath developers but not a Debian developer.
On Sat, 2003-09-06 at 01:47, Jan Schulz wrote:
> Chapter 2. Policy
>
> Packages written in Java are separated in two categories: programs
> and libraries. Programs are intended to be run by end-users.
> Libraries are intend
Hallo Jan,
Just a smal update, which I forgot last night...
* Jan Schulz wrote:
>2.6. Java programs
[...]
>Applications may honor the user set JAVA_HOME evironment variable,
>while looking for a useable java virtual maschine. If so, this must
>be clearly stated in the manpage and, if possible, a
Hi. Just a few more notes on this.
> Java libraries must depend on the needed working runtime
> environments, including the virtual package names of working
> versions of the "unfree" bin/java interface.
(and a similar clause for java programs)
If you're going to mandate that developers keep a
Hallo Jan,
Just a smal update, which I forgot last night...
* Jan Schulz wrote:
>2.6. Java programs
[...]
>Applications may honor the user set JAVA_HOME evironment variable,
>while looking for a useable java virtual maschine. If so, this must
>be clearly stated in the manpage and, if possible, a
100 matches
Mail list logo
