Deprecated features are still available. There are still tagged, so that
their use is discouraged, since they might be removed in a later
release. As far as I know, nothing has ever been removed yet.
Technically, if a package requires the java1 API, it will run with a
java2 implementation. So I
Deprecated features are still available. There are still tagged, so that
their use is discouraged, since they might be removed in a later
release. As far as I know, nothing has ever been removed yet.
Technically, if a package requires the java1 API, it will run with a
java2 implementation. So I
In message: <[EMAIL PROTECTED]>
Daniel Bonniot <[EMAIL PROTECTED]> writes:
>
>>>I would think that java2 is a superset of java1.
>>
>>Unfortunately, this is not the case; the deprecation of methods and
>>classes make java2 an intersecting set, not a superset of java1.
>
>Deprecated fe
In message: <[EMAIL PROTECTED]>
Daniel Bonniot <[EMAIL PROTECTED]> writes:
>
>>>I would think that java2 is a superset of java1.
>>
>>Unfortunately, this is not the case; the deprecation of methods and
>>classes make java2 an intersecting set, not a superset of java1.
>
>Deprecated fe
On Sat, Aug 16, 2003 at 02:36:08AM -0500, Mike Maurer wrote:
> Currently this is true of the official and blackdown implementations. I've
> never
> seen anything that says deprecated methods are guaranteed to exist until API
> version X, or that they're guranteed to be removed by version X. So I
On Sat, Aug 16, 2003 at 02:36:08AM -0500, Mike Maurer wrote:
> Currently this is true of the official and blackdown implementations. I've never
> seen anything that says deprecated methods are guaranteed to exist until API
> version X, or that they're guranteed to be removed by version X. So I wo
On Fri, Aug 15, 2003 at 11:38:42PM +0200, Daniel Bonniot wrote:
>
> Deprecated features are still available. There are still tagged, so that
> their use is discouraged, since they might be removed in a later
> release. As far as I know, nothing has ever been removed yet.
> Technically, if a pack
On Fri, Aug 15, 2003 at 11:38:42PM +0200, Daniel Bonniot wrote:
>
> Deprecated features are still available. There are still tagged, so that
> their use is discouraged, since they might be removed in a later
> release. As far as I know, nothing has ever been removed yet.
> Technically, if a pack
On Fri, 15 Aug 2003 23:38:42 +0200
Daniel Bonniot <[EMAIL PROTECTED]> wrote:
> > > I would think that java2 is a superset of java1.
> >
> > Unfortunately, this is not the case; the deprecation of methods and
> > classes make java2 an intersecting set, not a superset of java1.
>
> Deprecated feat
I would think that java2 is a superset of java1.
Unfortunately, this is not the case; the deprecation of methods and
classes make java2 an intersecting set, not a superset of java1.
Deprecated features are still available. There are still tagged, so that
their use is discouraged, since they
On Fri, 15 Aug 2003 23:38:42 +0200
Daniel Bonniot <[EMAIL PROTECTED]> wrote:
> > > I would think that java2 is a superset of java1.
> >
> > Unfortunately, this is not the case; the deprecation of methods and
> > classes make java2 an intersecting set, not a superset of java1.
>
> Deprecated feat
I would think that java2 is a superset of java1.
Unfortunately, this is not the case; the deprecation of methods and
classes make java2 an intersecting set, not a superset of java1.
Deprecated features are still available. There are still tagged, so that
their use is discouraged, since they
In message: <[EMAIL PROTECTED]>
Daniel Bonniot <[EMAIL PROTECTED]> writes:
>I would think that java2 is a superset of java1.
Unfortunately, this is not the case; the deprecation of methods and
classes make java2 an intersecting set, not a superset of java1.
>I propose the following
In message: <[EMAIL PROTECTED]>
Daniel Bonniot <[EMAIL PROTECTED]> writes:
>I would think that java2 is a superset of java1.
Unfortunately, this is not the case; the deprecation of methods and
classes make java2 an intersecting set, not a superset of java1.
>I propose the following
In which case fixing dpkg strikes me as far better than adding yet more
byzantine workarounds.
I'm all for somebody working on improving dpkg. At the same time, I know
this is a limitation that has been known for a long time, so it might
not be easy to fix, and will probably need some more time.
On Friday 15 August 2003 11:34, Stefan Gybas wrote:
> David Goodenough wrote:
> > Surely this says that having explicit runtime-? virtual packages is the
> > wrong way to go. What is needed is that the virtual package has a
> > version and then it can be compared in the normal way.
>
> Yes, but un
David Goodenough wrote:
Surely this says that having explicit runtime-? virtual packages is the wrong
way to go. What is needed is that the virtual package has a version and then
it can be compared in the normal way.
Yes, but unfortunately dpkg does not support versioned Provides: (see
#112131),
On Friday 15 August 2003 11:02, Philipp Meier wrote:
> On Fri, Aug 15, 2003 at 01:10:42PM +0200, Daniel Bonniot wrote:
> > I propose the following changes in the policy, instead of the above
> > paragraphs:
> >
> > Programs /must/ depend on /java-virtual-machine/ and the needed runtime
> > environm
On Fri, Aug 15, 2003 at 01:10:42PM +0200, Daniel Bonniot wrote:
> I propose the following changes in the policy, instead of the above
> paragraphs:
>
> Programs /must/ depend on /java-virtual-machine/ and the needed runtime
> environment (/java1-runtime/ or /java2-runtime/).
>
> [JVMs] can als
In which case fixing dpkg strikes me as far better than adding yet more
byzantine workarounds.
I'm all for somebody working on improving dpkg. At the same time, I know
this is a limitation that has been known for a long time, so it might
not be easy to fix, and will probably need some more time.
On Friday 15 August 2003 11:34, Stefan Gybas wrote:
> David Goodenough wrote:
> > Surely this says that having explicit runtime-? virtual packages is the
> > wrong way to go. What is needed is that the virtual package has a
> > version and then it can be compared in the normal way.
>
> Yes, but un
Hi,
I was reported that my package, which "Depends: java-virtual-machine,
java1-runtime", could not be installed of a user's machine, who has
blackdown's j2sdk1.4 and j2re1.4 installed. j2re1.4 "Provides:
java-virtual-machine, java2-runtime".
Something seems to be wrong, since the package should
David Goodenough wrote:
Surely this says that having explicit runtime-? virtual packages is the wrong
way to go. What is needed is that the virtual package has a version and then
it can be compared in the normal way.
Yes, but unfortunately dpkg does not support versioned Provides: (see
#112131),
On Friday 15 August 2003 11:02, Philipp Meier wrote:
> On Fri, Aug 15, 2003 at 01:10:42PM +0200, Daniel Bonniot wrote:
> > I propose the following changes in the policy, instead of the above
> > paragraphs:
> >
> > Programs /must/ depend on /java-virtual-machine/ and the needed runtime
> > environm
On Fri, Aug 15, 2003 at 01:10:42PM +0200, Daniel Bonniot wrote:
> I propose the following changes in the policy, instead of the above
> paragraphs:
>
> Programs /must/ depend on /java-virtual-machine/ and the needed runtime
> environment (/java1-runtime/ or /java2-runtime/).
>
> [JVMs] can als
Hi,
I was reported that my package, which "Depends: java-virtual-machine,
java1-runtime", could not be installed of a user's machine, who has
blackdown's j2sdk1.4 and j2re1.4 installed. j2re1.4 "Provides:
java-virtual-machine, java2-runtime".
Something seems to be wrong, since the package shoul
26 matches
Mail list logo
