Hi Ben,
On Thu, 27 Sep 2001, Ben Burton wrote:
>
> > Looks good mate - one question though: How can a startup script for a
> > pre-packaged application (or alternatively one of the pre-packaged
> > recognition scripts) find out which registry file it should read when
> > more tha
Hi Ben,
On Thu, 27 Sep 2001, Ben Burton wrote:
>
> > Looks good mate - one question though: How can a startup script for a
> > pre-packaged application (or alternatively one of the pre-packaged
> > recognition scripts) find out which registry file it should read when
> > more th
> Looks good mate - one question though: How can a startup script for a
> pre-packaged application (or alternatively one of the pre-packaged
> recognition scripts) find out which registry file it should read when
> more than one debianised jvm package is installed ? Do you
Hi Ben,
On Tue, 11 Sep 2001, Ben Burton wrote:
> So. What I propose is to create a JVM registry. This will be in a
> ...
>
> Following this, package java-common would provide:
>
> - The registry directory itself (eg. /usr/share/java/registry);
> - A set of scripts that query the registry
> Looks good mate - one question though: How can a startup script for a
> pre-packaged application (or alternatively one of the pre-packaged
> recognition scripts) find out which registry file it should read when
> more than one debianised jvm package is installed ? Do you
Hi Ben,
On Tue, 11 Sep 2001, Ben Burton wrote:
> So. What I propose is to create a JVM registry. This will be in a
> ...
>
> Following this, package java-common would provide:
>
> - The registry directory itself (eg. /usr/share/java/registry);
> - A set of scripts that query the registry
* Ola Lundqvist
| We do now have the problem of versioning. But is it possible to
| "Provide: foo.jar (= 1.2.3)".
|
| If not that should be a great advantage.
Versioned provides aren't supported, and as Andrew writes -- this will
just lead us into file-dependency hell. Not a good idea, imho.
* Ola Lundqvist
| We do now have the problem of versioning. But is it possible to
| "Provide: foo.jar (= 1.2.3)".
|
| If not that should be a great advantage.
Versioned provides aren't supported, and as Andrew writes -- this will
just lead us into file-dependency hell. Not a good idea, imho.
On Fri, Sep 14, 2001 at 06:18:19PM +0200, Ola Lundqvist wrote:
> The problem I was talking about was that some packages can
> provide and depend on specific jar packages, and maybe with
> a specific version of that package.
>
> So why not just "Provides: foo.jar, bar.jar" and then depend on the
>
[ Another late reply from me. ]
My gut reaction is that this is the right thing.
Currently, I think most of us would agree, Debian packaging of Java
software is not that successful. I think this is in part due to the
variety of available implementations of various portions of the
various Java pl
On Fri, Sep 14, 2001 at 06:18:19PM +0200, Ola Lundqvist wrote:
> The problem I was talking about was that some packages can
> provide and depend on specific jar packages, and maybe with
> a specific version of that package.
>
> So why not just "Provides: foo.jar, bar.jar" and then depend on the
>
[ Another late reply from me. ]
My gut reaction is that this is the right thing.
Currently, I think most of us would agree, Debian packaging of Java
software is not that successful. I think this is in part due to the
variety of available implementations of various portions of the
various Java p
On Fri, Sep 14, 2001 at 04:45:42PM -0500, Ben Burton wrote:
>
> Just a couple of notes; I'll think about this over the weekend too.
> The first thing I should say is that this registry is *not* primarily
> intended for end users; it's mostly provided to aid startup scripts for
> other packages;
On Fri, Sep 14, 2001 at 04:45:42PM -0500, Ben Burton wrote:
>
> Just a couple of notes; I'll think about this over the weekend too.
> The first thing I should say is that this registry is *not* primarily
> intended for end users; it's mostly provided to aid startup scripts for
> other packages
Just a couple of notes; I'll think about this over the weekend too.
The first thing I should say is that this registry is *not* primarily
intended for end users; it's mostly provided to aid startup scripts for
other packages; to allow them to be friendlier and to break under fewer
system configur
Just a couple of notes; I'll think about this over the weekend too.
The first thing I should say is that this registry is *not* primarily
intended for end users; it's mostly provided to aid startup scripts for
other packages; to allow them to be friendlier and to break under fewer
system configu
On Tue, Sep 11, 2001 at 02:35:41PM -0500, Ben Burton wrote:
>
> (btw, I have switched on a television since I wrote the following email;
> my thoughts are with everyone in the US and others connected to the
> incident.)
>
> As it stands, a machine may have many JVMs installed, all of which
> prov
On Tue, Sep 11, 2001 at 02:35:41PM -0500, Ben Burton wrote:
CUT.
My mail have not arrived to the list yet so I reply to this mail
instead. Because something just strucked me!
The problem I was talking about was that some packages can
provide and depend on specific jar packages, and maybe with
a s
On Tue, Sep 11, 2001 at 02:35:41PM -0500, Ben Burton wrote:
>
> (btw, I have switched on a television since I wrote the following email;
> my thoughts are with everyone in the US and others connected to the
> incident.)
>
> As it stands, a machine may have many JVMs installed, all of which
> pro
On Tue, Sep 11, 2001 at 02:35:41PM -0500, Ben Burton wrote:
CUT.
My mail have not arrived to the list yet so I reply to this mail
instead. Because something just strucked me!
The problem I was talking about was that some packages can
provide and depend on specific jar packages, and maybe with
a
On Wednesday 12 September 2001 17:30, Ben Burton wrote:
> > What about using XML instead?
>
> The initial reason for suggesting plain text was that (1) it seemed like
> it would handle the task well enough, i.e. I didn't see a natural tree
> structure on the data, and (2) it's easier to inspect and
> What about using XML instead?
The initial reason for suggesting plain text was that (1) it seemed like
it would handle the task well enough, i.e. I didn't see a natural tree
structure on the data, and (2) it's easier to inspect and edit by hand.
Having said that, I'm personally not fussed in t
[ snip ]
> The file will look similar to a debian control file; for
> example:
[ snip ]
What about using XML instead?
/Nils
> First: certain programs not running with certain JVMs. This can be
> addressed a lot quicker by simply having those packages either Conflicts:
> with that JVM package...
Not true. You can have several JVMs installed at once; having BadJVM
installed doesn't stop me from using FunkyApp with Goo
On Wednesday 12 September 2001 17:30, Ben Burton wrote:
> > What about using XML instead?
>
> The initial reason for suggesting plain text was that (1) it seemed like
> it would handle the task well enough, i.e. I didn't see a natural tree
> structure on the data, and (2) it's easier to inspect an
> What about using XML instead?
The initial reason for suggesting plain text was that (1) it seemed like
it would handle the task well enough, i.e. I didn't see a natural tree
structure on the data, and (2) it's easier to inspect and edit by hand.
Having said that, I'm personally not fussed in
[ snip ]
> The file will look similar to a debian control file; for
> example:
[ snip ]
What about using XML instead?
/Nils
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
> First: certain programs not running with certain JVMs. This can be
> addressed a lot quicker by simply having those packages either Conflicts:
> with that JVM package...
Not true. You can have several JVMs installed at once; having BadJVM
installed doesn't stop me from using FunkyApp with Go
On Tue, Sep 11, 2001 at 02:35:41PM -0500, Ben Burton wrote:
> So. What I propose is to create a JVM registry.
Alarm bells start going off when I hear "registry". Not knee-jerk
"registries much suck 'coz M$ does 'em", but bells nonetheless. This
seems like way too heavy-duty a solution for the
On Tue, Sep 11, 2001 at 02:35:41PM -0500, Ben Burton wrote:
> So. What I propose is to create a JVM registry.
Alarm bells start going off when I hear "registry". Not knee-jerk
"registries much suck 'coz M$ does 'em", but bells nonetheless. This
seems like way too heavy-duty a solution for the
(btw, I have switched on a television since I wrote the following email;
my thoughts are with everyone in the US and others connected to the
incident.)
As it stands, a machine may have many JVMs installed, all of which
provide no information via package management other than provides:
java-virtua
(btw, I have switched on a television since I wrote the following email;
my thoughts are with everyone in the US and others connected to the
incident.)
As it stands, a machine may have many JVMs installed, all of which
provide no information via package management other than provides:
java-virtu
32 matches
Mail list logo
