> Well we have both ways in debian now. Should we allow both but prefer
> one?
Seeing as we're moving to enforce a single consistent standard, I'm
personally happier if we only allow one.
Looking through what the approximate list of all available java packages
(see first post to this thread) I
On Sat, Sep 15, 2001 at 04:42:14PM -0500, Ben Burton wrote:
>
> > I suggest that we name the packages libfoo-java or in some
> > cases libfoo-version-java if that are necessary.
> >
> > Is that ok if I change the policy in that way?
>
> Fine in general with me, although I have a question about v
On Thu, Sep 13, 2001 at 08:55:04PM +1000, jeff wrote:
> But I'll spare you that ranting; let's just say I think it's a
> horrifically bad idea to have a free-for-all in one's classpath.
I tend to agree, though I should point out that the opposite view
has support. For example, Per Bothner said in
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 Thu, Sep 13, 2001 at 08:55:04PM +1000, jeff wrote:
> But I'll spare you that ranting; let's just say I think it's a
> horrifically bad idea to have a free-for-all in one's classpath.
I tend to agree, though I should point out that the opposite view
has support. For example, Per Bothner said i
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
> I suggest that we name the packages libfoo-java or in some
> cases libfoo-version-java if that are necessary.
>
> Is that ok if I change the policy in that way?
Fine in general with me, although I have a question about versions. Do we
want libfoo-version-java or libfooversion-java? To me a pa
Hi Joe,
The suggestions here are all good and sensible, but are based on one big
assumption: that the classpath should be set to *anything* in the first place.
Why not just put the jars in /usr/share/java, keep the system classpath
completely clean, and let the startup scripts for individual apps
On Sat, Sep 15, 2001 at 09:34:45AM -0500, Ben Burton wrote:
>
> > > Does anyone have reasons why /usr/share/java/repository should remain?
> >
> > No do do not like that repository. Can we have some consensus about this?
> >
> > Should I remove it from the policy?
>
> Can we also remove the bulle
On Sat, Sep 15, 2001 at 12:29:35PM -0500, Ben Burton wrote:
>
> Okay. Note that java policy states that "Libraries packages must be named
> lib-XXX-java."
>
> Below we see an approximate list of all java library packages available in
> debian. One observes that more than *half* of them are name
On Saturday 15 September 2001 19:29, Ben Burton wrote:
> Okay. Note that java policy states that "Libraries packages must be named
> lib-XXX-java."
>
> Below we see an approximate list of all java library packages available in
> debian. One observes that more than *half* of them are named
> "libX
> I suggest that we name the packages libfoo-java or in some
> cases libfoo-version-java if that are necessary.
>
> Is that ok if I change the policy in that way?
Fine in general with me, although I have a question about versions. Do we
want libfoo-version-java or libfooversion-java? To me a p
> > Does this bother anyone else but me?
>
> Yes, it does, but not for the same reason.
Well, yes for the same reason, which is lack of adherence to a tidy
convention. If that convention can spread in general across libraries for
interpreted languages then all the better.
In which case I'm all
Hi Joe,
The suggestions here are all good and sensible, but are based on one big
assumption: that the classpath should be set to *anything* in the first place.
Why not just put the jars in /usr/share/java, keep the system classpath
completely clean, and let the startup scripts for individual app
On Sat, Sep 15, 2001 at 09:34:45AM -0500, Ben Burton wrote:
>
> > > Does anyone have reasons why /usr/share/java/repository should remain?
> >
> > No do do not like that repository. Can we have some consensus about this?
> >
> > Should I remove it from the policy?
>
> Can we also remove the bull
On Sat, Sep 15, 2001 at 12:29:35PM -0500, Ben Burton wrote:
>
> Okay. Note that java policy states that "Libraries packages must be named
> lib-XXX-java."
>
> Below we see an approximate list of all java library packages available in
> debian. One observes that more than *half* of them are nam
On Sat, 15 Sep 2001, Ola Lundqvist wrote:
> On Fri, Sep 14, 2001 at 04:23:47PM -0500, Ben Burton wrote:
> >
> > Seeing as java policy is getting a work through right now, I personally
> > have no problems with removing /usr/share/java/repository in favour of
> > versioned jars.
> >
> > Does anyone
Sorry for the large cc, but it is about time that debian had a unified policy
on these package names.
On Sat, 15 Sep 2001, Ben Burton wrote:
>
> Okay. Note that java policy states that "Libraries packages must be named
> lib-XXX-java."
I think the java policy is wrong. Why should java be any
Okay. Note that java policy states that "Libraries packages must be named
lib-XXX-java."
Below we see an approximate list of all java library packages available in
debian. One observes that more than *half* of them are named
"libXXX-java"
instead of "lib-XXX-java". We even see libpgjava with n
On Saturday 15 September 2001 19:29, Ben Burton wrote:
> Okay. Note that java policy states that "Libraries packages must be named
> lib-XXX-java."
>
> Below we see an approximate list of all java library packages available in
> debian. One observes that more than *half* of them are named
> "lib
> > Does this bother anyone else but me?
>
> Yes, it does, but not for the same reason.
Well, yes for the same reason, which is lack of adherence to a tidy
convention. If that convention can spread in general across libraries for
interpreted languages then all the better.
In which case I'm all
On Sat, 15 Sep 2001, Ola Lundqvist wrote:
> On Fri, Sep 14, 2001 at 04:23:47PM -0500, Ben Burton wrote:
> >
> > Seeing as java policy is getting a work through right now, I personally
> > have no problems with removing /usr/share/java/repository in favour of
> > versioned jars.
> >
> > Does anyon
Sorry for the large cc, but it is about time that debian had a unified policy
on these package names.
On Sat, 15 Sep 2001, Ben Burton wrote:
>
> Okay. Note that java policy states that "Libraries packages must be named
> lib-XXX-java."
I think the java policy is wrong. Why should java be any
Okay. Note that java policy states that "Libraries packages must be named
lib-XXX-java."
Below we see an approximate list of all java library packages available in
debian. One observes that more than *half* of them are named
"libXXX-java"
instead of "lib-XXX-java". We even see libpgjava with
On Fri, Sep 14, 2001 at 04:23:47PM -0500, Ben Burton wrote:
>
> Seeing as java policy is getting a work through right now, I personally
> have no problems with removing /usr/share/java/repository in favour of
> versioned jars.
>
> Does anyone have reasons why /usr/share/java/repository should rem
> > Does anyone have reasons why /usr/share/java/repository should remain?
>
> No do do not like that repository. Can we have some consensus about this?
>
> Should I remove it from the policy?
Can we also remove the bullet point under "Advice to Java Packagers" that
*recommends* using the reposit
On Fri, Sep 14, 2001 at 04:23:47PM -0500, Ben Burton wrote:
>
> Seeing as java policy is getting a work through right now, I personally
> have no problems with removing /usr/share/java/repository in favour of
> versioned jars.
>
> Does anyone have reasons why /usr/share/java/repository should re
> > Does anyone have reasons why /usr/share/java/repository should remain?
>
> No do do not like that repository. Can we have some consensus about this?
>
> Should I remove it from the policy?
Can we also remove the bullet point under "Advice to Java Packagers" that
*recommends* using the reposi
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:23:47PM -0500, Ben Burton wrote:
>
> Seeing as java policy is getting a work through right now, I personally
> have no problems with removing /usr/share/java/repository in favour of
> versioned jars.
>
> Does anyone have reasons why /usr/share/java/repository should rem
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:23:47PM -0500, Ben Burton wrote:
>
> Seeing as java policy is getting a work through right now, I personally
> have no problems with removing /usr/share/java/repository in favour of
> versioned jars.
>
> Does anyone have reasons why /usr/share/java/repository should re
Ben Burton wrote:
Currently the java libraries I package are in the form of:
/usr/share/java/foo-version.jar
/usr/share/java/foo.jar -> foo-version.jar
This is the most sensible choice - it works well for /lib, /usr/lib
so it should would well for jars.
The other problem with just having a reposi
35 matches
Mail list logo
