Hi all
On Thu, 14 Aug 2003 21:39:17 +0200
Jan Schulz <[EMAIL PROTECTED]> wrote:
libxalan2-java depends on libxerces2-java but you do not need
xml-apis.jar AND xmlParserAPIs.jar in your classpath. It's up to
the maintainer of the application to know what to do.
This will anyway have to
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
On Thu, 14 Aug 2003 21:39:17 +0200
Jan Schulz <[EMAIL PROTECTED]> wrote:
[...]
> Usually you need to know what version of what lib you need. If that
> version is packages, you add this package name to your Depends:
> dh_java (or yourself, if thats not oncluded in such a script) will
> then add t
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
Hi all
On Thu, 14 Aug 2003 21:39:17 +0200
Jan Schulz <[EMAIL PROTECTED]> wrote:
libxalan2-java depends on libxerces2-java but you do not need
xml-apis.jar AND xmlParserAPIs.jar in your classpath. It's up to
the maintainer of the application to know what to do.
This will anyway have to
On 15 Aug 2003 14:44:02 -0500
Ean Schuessler <[EMAIL PROTECTED]> wrote:
> I have built packages for 1.1.1 for Intel and they seem to work well
> enough.
Very good news! :-D
> Sorry again for my absentee behavior.
You're welcome ;)
-- Arnaud Vandyck, STE fi, ULg
Formateur Cellule Programma
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
Hi Ean,
My apologies. We installed a new mail server and I was in a car wreck
shortly after so some configuration issues went unattended. I have built
packages for 1.1.1 for Intel and they seem to work well enough. I need
to verify that I can stop using pthreads. Under 1.0.7 I could not get
ant to
On Thu, 14 Aug 2003 21:39:17 +0200
Jan Schulz <[EMAIL PROTECTED]> wrote:
[...]
> Usually you need to know what version of what lib you need. If that
> version is packages, you add this package name to your Depends:
> dh_java (or yourself, if thats not oncluded in such a script) will
> then add t
My apologies. We installed a new mail server and I was in a car wreck
shortly after so some configuration issues went unattended. I have built
packages for 1.1.1 for Intel and they seem to work well enough. I need
to verify that I can stop using pthreads. Under 1.0.7 I could not get
ant to spawn ex
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 15 Aug 2003 14:44:02 -0500
Ean Schuessler <[EMAIL PROTECTED]> wrote:
> I have built packages for 1.1.1 for Intel and they seem to work well
> enough.
Very good news! :-D
> Sorry again for my absentee behavior.
You're welcome ;)
-- Arnaud Vandyck, STE fi, ULg
Formateur Cellule Programma
Hi Ean,
My apologies. We installed a new mail server and I was in a car wreck
shortly after so some configuration issues went unattended. I have built
packages for 1.1.1 for Intel and they seem to work well enough. I need
to verify that I can stop using pthreads. Under 1.0.7 I could not get
ant to
My apologies. We installed a new mail server and I was in a car wreck
shortly after so some configuration issues went unattended. I have built
packages for 1.1.1 for Intel and they seem to work well enough. I need
to verify that I can stop using pthreads. Under 1.0.7 I could not get
ant to spawn ex
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
On Fri, Aug 15, 2003 at 10:46:03AM -0400, Matt Zimmerman wrote:
> On Fri, Aug 15, 2003 at 04:35:00PM +0200, Philipp Meier wrote:
>
> > On Fri, Aug 15, 2003 at 10:13:42AM -0400, Matt Zimmerman wrote:
> > > This sounds useful. I think it could be simplified to use comm(1) rather
> > > than parsing
On Fri, Aug 15, 2003 at 04:35:00PM +0200, Philipp Meier wrote:
> On Fri, Aug 15, 2003 at 10:13:42AM -0400, Matt Zimmerman wrote:
> > This sounds useful. I think it could be simplified to use comm(1) rather
> > than parsing a unified diff, though.
>
> grep -f is more useful. See attached script.
On Fri, Aug 15, 2003 at 10:13:42AM -0400, Matt Zimmerman wrote:
> On Thu, Aug 14, 2003 at 10:56:50PM +0200, Stefan Gybas wrote:
>
> > I've written a little script to compare the contents of two JARs. I've
> > used it compare Debian packages with upstream binaries so I know that
> > the build pro
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
On Thu, Aug 14, 2003 at 10:56:50PM +0200, Stefan Gybas wrote:
> I've written a little script to compare the contents of two JARs. I've
> used it compare Debian packages with upstream binaries so I know that
> the build process worked fine, for example when using CDBS or Ant and
> Kaffe from mai
On Fri, Aug 15, 2003 at 10:46:03AM -0400, Matt Zimmerman wrote:
> On Fri, Aug 15, 2003 at 04:35:00PM +0200, Philipp Meier wrote:
>
> > On Fri, Aug 15, 2003 at 10:13:42AM -0400, Matt Zimmerman wrote:
> > > This sounds useful. I think it could be simplified to use comm(1) rather
> > > than parsing
On Fri, Aug 15, 2003 at 04:35:00PM +0200, Philipp Meier wrote:
> On Fri, Aug 15, 2003 at 10:13:42AM -0400, Matt Zimmerman wrote:
> > This sounds useful. I think it could be simplified to use comm(1) rather
> > than parsing a unified diff, though.
>
> grep -f is more useful. See attached script.
On Thu, 14 Aug 2003 22:56:50 +0200
Stefan Gybas <[EMAIL PROTECTED]> wrote:
> I've written a little script to compare the contents of two JARs. I've
> used it compare Debian packages with upstream binaries so I know that
> the build process worked fine, for example when using CDBS or Ant and
> K
On Fri, Aug 15, 2003 at 10:13:42AM -0400, Matt Zimmerman wrote:
> On Thu, Aug 14, 2003 at 10:56:50PM +0200, Stefan Gybas wrote:
>
> > I've written a little script to compare the contents of two JARs. I've
> > used it compare Debian packages with upstream binaries so I know that
> > the build pro
On Thu, Aug 14, 2003 at 10:56:50PM +0200, Stefan Gybas wrote:
> I've written a little script to compare the contents of two JARs. I've
> used it compare Debian packages with upstream binaries so I know that
> the build process worked fine, for example when using CDBS or Ant and
> Kaffe from mai
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 Thu, 14 Aug 2003 22:56:50 +0200
Stefan Gybas <[EMAIL PROTECTED]> wrote:
> I've written a little script to compare the contents of two JARs. I've
> used it compare Debian packages with upstream binaries so I know that
> the build process worked fine, for example when using CDBS or Ant and
> K
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
38 matches
Mail list logo
