Stefan Gybas <[EMAIL PROTECTED]> writes:
> I fully agree with you! The only useful things in the
> current Java Policy are /usr/share/java for JARs, /usr/lib/jni
> and the naming of library packages. Everything else is based
> on wrong assumtions. :-(
I also agree.
--
.''`.
:
Jerry Haltom <[EMAIL PROTECTED]> writes:
> What I think we MUST do is aim to have a end user application, that
> runs on Java, work as expected. To this end, I see java2-runtime being
> provided by runtimes that conform to Sun's published standards, and no
> others. However we verify that i
Hi Jerry,
Jerry Haltom wrote:
What I think we MUST do is aim to have a end user application, that runs
on Java, work as expected. To this end, I see java2-runtime being
provided by runtimes that conform to Sun's published standards, and no
others. However we verify that is up in the air. Addition
Only one comment inline.
On Tue, 2004-01-20 at 17:35, Stefan Gybas wrote:
> [Not CC'ing the bug since it's not related to it]
>
> Jan Schulz wrote:
>
> > Which version? The content changed quite havily with the discussion :)
>
> The original one. As I've said, I've not yet read the discussion y
Hallo Stefan,
* Stefan Gybas wrote:
>[Not CC'ing the bug since it's not related to it]
Thought so, too, but was too lazy :)
>Jan Schulz wrote:
>>Which version? The content changed quite havily with the discussion :)
>The original one. As I've said, I've not yet read the discussion yet.
Hm, be
[Not CC'ing the bug since it's not related to it]
Jan Schulz wrote:
Which version? The content changed quite havily with the discussion :)
The original one. As I've said, I've not yet read the discussion yet.
I'll send my comments in a couple of days so we can discuss all this at
FOSDEM.
Even
Hallo Stefan,
* Stefan Gybas wrote:
>I've read Jan's proposal yesterday (but not the following discussion
>with Dalibor and others, so I won't comment yet)
Which version? The content changed quite havily with the discussion :)
>and I don't see how his
>proposal solves this problem. AFAICS his
> > And this is my core problem with your proposal. You want to remove
> > j2/1-runtime, but you offer nothing whatsoever to replace it.
>
> No, I don't. Java applications must still depend on the required
> java*-runtime virtual packages, I just want this dependency removed for
> library pack
Ben Burton wrote:
And this is my core problem with your proposal. You want to remove
j2/1-runtime, but you offer nothing whatsoever to replace it.
No, I don't. Java applications must still depend on the required
java*-runtime virtual packages, I just want this dependency removed for
library pac
Stefan Gybas <[EMAIL PROTECTED]> writes:
> Library packages never depended on a JVM (virtual package
> java-virtual-machine), just the core classes. The definition of
> java*-runtime means just the core classes, no JVM. Ola has clarified
> this in
> http://lists.debian.org/debian-devel/2002/debian
> > Thus the *absence* of java2-runtime in the depends list is
> > an indication that the package should work on most JVMs in
> > debian. I would however expect these packages to run under
> > java2 as well.
>
> In my understanding the absence of java2-runtime means that a package
> that (solel
> > * j2/1-runtime does not garantee anything *at runtime*, so it is
>
> Right. That's exaclty the reason why I'd like to see them removed for
> library packages. But I guess I have already told this... :)
And this is my core problem with your proposal. You want to remove
j2/1-runtime, but you
Hallo Jan, Hi Stefan,
Jan Schulz wrote:
It's not flaming. It's just a discussion with some misunderstanding. ;-)
I know :) I've had my share of them during the proposal discussion :)
Yeah, we had joy, we had fun, ... ;)
That would be great! Anyway, I will wait for the result of our 'common
pa
Hi Stefan,
Stefan Gybas wrote:
Ok, this seems to be another misunderstanding: I want Java libraries to
depend on all APIs except for the core APIs. I simply assume that
libraries work with any JVM/JRE, although this might not be correct.
One of the funnier things last year was that ant had an 1
Hallo Stefan,
Do you want to be included in the reply?
* Stefan Gybas wrote:
>I think you are making the same mistake as Ben here: java*-runtime just
>means the core classes, no JVM! If you need both, you need to depend on
Hm, j-v-m us a even better exapmle for a policy redesign. Is there any
Jan Schulz wrote:
* j2/1-runtime does not garantee anything *at runtime*, so it is
Right. That's exaclty the reason why I'd like to see them removed for
library packages. But I guess I have already told this... :)
useless in that respect. IMO, and that was the result of the policy
discusion
Ben Burton wrote:
Thus the *absence* of java2-runtime in the depends list is
an indication that the package should work on most JVMs in
debian. I would however expect these packages to run under
java2 as well.
In my understanding the absence of java2-runtime means that a package
that (solely) pr
Hallo Stefan, Hi Ben,
I'm just cutting in here...
* Stefan Gybas wrote:
>Ben Burton wrote:
>You still have not answered my questions about JUnit: Which package do
>you want in Debian? A stripped version without Swing GUI in main or a
>full version in contrib? Which one do you want to ship with
Regarding jython and libreadline-java, I think we've had a small
communiation breakdown. What I meant is that there are packages that
do not require java2-runtime, i.e., that only use the 1.1 API.
Thus the *absence* of java2-runtime in the depends list is
an indication that the package should wor
Ben Burton wrote:
I invite you to try apt-cache showpkg. Btw, I maintain two of them
(jython and libreadline-java), both of which can be used as libraries.
$ dpkg -p jython
[...]
Depends: gij | java-virtual-machine, gij | java1-runtime |
java2-runtime, libreadline-java (>= 0.6), python2.
> Non of them even implements the full JDK 1.1 API so they also shouldn't
> provide java1-runtime unless you change the definition of the
> java1-runtime virtual package.
We've already had this argument. The java*-runtime virtual packages
are a loosely defined system for which Jan already has
Ben Burton wrote:
Yes it does. It tells us that the lib/app won't work with java1 alone.
Right. But it might work with Kaffe, GIJ and SavleVM. None of them
provides java2-runtime since they don't implement the full JDK 1.2+ API.
Non of them even implements the full JDK 1.1 API so they also shou
Hi again.
> I think we can assume that all libraries work with java2-runtime, at
> least I have not seen one that requires java1-runtime and does not work
> with "JDK 1.2 and above". The next problem is that java2-runtime means
> "JDK 1.2 core classes and above" but there's no way to specify "
Ben Burton wrote:
I do not like deleting this requirement. Although there are some
serious problems with it (such as different libraries working to
different degrees on different JVMs), removing this dependency will
not solve these problems - it will in fact give the user *less*
information regar
Ben Burton wrote:
I would encourage changing "should suggest" to "may suggest or recommend".
Agreed.
Stefan
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Hi. Further on this proposal:
> Java libraries must depend on the needed runtime environment
> (java1-runtime and/or java2-runtime) ...
I do not like deleting this requirement. Although there are some
serious problems with it (such as different libraries working to
different degrees on differe
> Java library packages must depend on other library packages if they
> can't be used without them. If other libraries are only required by
> parts of the library, they should suggest the required library package
> instead.
This paragraph really seems like it's just restating standard
debian p
Package: java-common
Version: 0.22
Severity: wishlist
I propose to change the following paragraph in section 2.4. of the
Debian Java policy
> Java libraries must depend on the needed runtime environment
> (java1-runtime and/or java2-runtime) but should not depend (only
> suggest) java-virtual-mac
28 matches
Mail list logo
