reassign 553619 java-common
thanks
Le Sun, Nov 01, 2009 at 04:46:56PM +0200, Tom Feiner a écrit :
> Subject: debian-policy: include java policy
> Package: debian-policy
> Version: 3.8.3.0
> Severity: wishlist
>
> Currently, the java policy is provided as part of the jav
Processing commands for cont...@bugs.debian.org:
> reassign 553619 java-common
Bug #553619 [debian-policy] debian-policy: include java policy
Bug reassigned from package 'debian-policy' to 'java-common'.
No longer marked as found in versions debian-policy/3.8.3.0.
Ignoring
Subject: debian-policy: include java policy
Package: debian-policy
Version: 3.8.3.0
Severity: wishlist
Currently, the java policy is provided as part of the java-common
package. However, its not clear if it is an official policy or a work in
progress.
Is it possible to add the java policy to
This sounds reasonable. Could you file a wishlist bug against
java-common with this? It would really be nice.
Regards,
// Ola
On Mon, Sep 02, 2002 at 11:53:30AM -0700, Per Bothner wrote:
> gcj also by default searches in jars in /usr/share/java/ext.
> The policy could add in 2.4:
>
> Java libr
gcj also by default searches in jars in /usr/share/java/ext.
The policy could add in 2.4:
Java libraries packages *may* add a sympolic link from
/usr/share/java/ext/packagename[-extraname].jar to
/usr/share/java/packagename[-extraname]-fullversion.jar.
In 2.1 Virtual machines:
If a virtual
gt; There are some things that might want to be added before it
> > becomes truly official.
> >
> > See the policy at:
> > http://www.debian.org/doc/packaging-manuals/java-policy/
> >
> > * gcj and how to handle that (should it be mentioned at all?).
>
>
Ola Lundqvist <[EMAIL PROTECTED]> writes:
> There are some things that might want to be added before it
> becomes truly official.
>
> See the policy at:
> http://www.debian.org/doc/packaging-manuals/java-policy/
>
> * gcj and how to handle that (should it be mentio
Hi
Now when woody is released I would like to propose that the
proposed java policy will be official.
Therefore I would like to have comments on it here so things
can be discussed. If you have a additional proposal please
also file a bug against java-common so I can remember it.
There are some
e care of
Ola> that.
Ola> Actually I'm thinking of splitting java-common in three. *
Ola> java-common (which should provide some help scripts and suggest
Ola> or depend on things). * java-policy (With the policy). *
Ola> java-faq (with the faq).
Ola> What do you
f that.
Actually I'm thinking of splitting java-common in three.
* java-common (which should provide some help scripts and suggest or
depend on things).
* java-policy (With the policy).
* java-faq (with the faq).
What do you think about that?
Regards,
// Ola
> --
> Ian Zimmerman, Oakl
seems reasonable to
> Andrew> me to allow both of these.
>
> Does this really need to be part of the java policy? I thought the
> Java policy was really aimed only at things that would install .class
> or .jar files.
>
> Naming it the "java" policy is perhaps a bi
>>>>> "Andrew" == Andrew Pimlott <[EMAIL PROTECTED]> writes:
Andrew> seems to forbid both code with native parts, and Java code
Andrew> compiled to machine binaries with gcj. It seems reasonable to
Andrew> me to allow both of these.
Does this reall
Jim Pick wrote:
>
> Because the set of Java APIs is so large, trying to develop a set of
> class libraries that works as a drop in replacement for Sun's libraries
> is a very large task. In reality, it's going to be a long time before
> the free java class library projects manage to reimplement 1
On Sun, May 12, 2002 at 09:15:31PM -0700, Jim Pick wrote:
> I think the Debian Java policy, as currently stated, is slightly flawed,
> as it tries to satisfy two goals that aren't completely orthogonal:
>
> 1) To get as much free Java software into Debian as possible, that runs
On Sun, May 12, 2002 at 06:22:30PM -0700, Jim Pick wrote:
> Sounds like Debian could use the same solution for gcj that Debian uses
> for emacs -> just distribute the .java files and do the ahead-of-time
> compilation (.java to .so) at install time. Is this automatic enough
> under gcj so that thi
On Monday 13 May 2002 03:22, Jim Pick wrote:
> Sounds like Debian could use the same solution for gcj that Debian uses
> for emacs -> just distribute the .java files and do the ahead-of-time
> compilation (.java to .so) at install time. Is this automatic enough
> under gcj so that this could that
I think the Debian Java policy, as currently stated, is slightly flawed,
as it tries to satisfy two goals that aren't completely orthogonal:
1) To get as much free Java software into Debian as possible, that runs
without non-free software (eg. without Sun's JDK)
2) To put
> "Rick" == Rick Lutowski <[EMAIL PROTECTED]> writes:
[long sequence of valid comments about JCK elided]
Rick> In the meantime, efforts such as this packaging policy would
Rick> do well to keep the definitions straight. To say things
Rick> like "native code != Java" and then base
> "Adam" == Adam Heath <[EMAIL PROTECTED]> writes:
Adam> HELL NO!
Why don't you tell us how you really feel, Adam :)
--
Stephen
"If I claimed I was emporer just cause some moistened bint lobbed a
scimitar at me they'd put me away"
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a
Ola Lundqvist wrote:
>
> Well I do not really understand this. Java code is supposed to be
> portable. If you compile it to machine binaries it is no longer a
> java program and should not be packaged as a such. Non java
> components should be extracted to a separate package IMHO.
I'm staying out
On Sun, 2002-05-12 at 17:16, Adam Heath wrote:
> On 12 May 2002, Jim Pick wrote:
>
> > Also, as the upstream kaffe maintainer, I'd really like it if for each
> > package that was stuck in contrib because kaffe can't run it (eg.
> > unimplemented APIs, etc), there was a "wishlist" bug filed against
On Sun, 2002-05-12 at 18:29, Per Bothner wrote:
> Jim Pick wrote:
> > Sounds like Debian could use the same solution for gcj that Debian uses
> > for emacs -> just distribute the .java files and do the ahead-of-time
> > compilation (.java to .so) at install time. Is this automatic enough
> > under
On Sun, 12 May 2002, Per Bothner wrote:
> Also, what happens if you install a Java package, and then install
> gcj later? Shuld that so the compilation to .so when you install
> gcj?
Each emacs extension packages places hooks into a site-wide dir. Then, all
the emacsen are processed over each f
On 12 May 2002, Jim Pick wrote:
> Sounds like Debian could use the same solution for gcj that Debian uses
> for emacs -> just distribute the .java files and do the ahead-of-time
> compilation (.java to .so) at install time. Is this automatic enough
> under gcj so that this could that work?
Let m
Jim Pick wrote:
Sounds like Debian could use the same solution for gcj that Debian uses
for emacs -> just distribute the .java files and do the ahead-of-time
compilation (.java to .so) at install time. Is this automatic enough
under gcj so that this could that work?
I think it would be too sl
> > There are many other free JVMs now: ORP, KissMe, etc...
>
> I am not very happy with trying to compile some Java code (e.g. Jmol
> jmol.sf.net) with every free JVM to see wether it can be done with that...
You should only have to compile the class files once (the classes should
still work,
Sounds like Debian could use the same solution for gcj that Debian uses
for emacs -> just distribute the .java files and do the ahead-of-time
compilation (.java to .so) at install time. Is this automatic enough
under gcj so that this could that work?
Granted, the emacs solution is currently a bit
Adam Heath wrote:
I've got a makefile based build system, that supports jdk-like jvms(kaffe,
sun, blackdown, ibm), and gcj(which has a different cmdline format).
Kawa (http://www.gnu.org/software/kawa) includes both an ant buildfile,
and an autotools-based (automake+autoconf+libtool) system. T
On Sun, May 12, 2002 at 05:03:54PM -0700, Stephen Zander wrote:
> > "Andrew" == Andrew Pimlott <[EMAIL PROTECTED]> writes:
> Andrew> No it's not. But you can use the gcj produced .so files
> Andrew> with gcj. If I do all my Java development with gcj,
> Andrew> Debian packages cont
On Sun, 12 May 2002, Andrew Pimlott wrote:
> Ok, then it is just a question of naming. Say my foo library can be
> compiled to .class files and GCJ .so files. One option is to
> package both in libfoo-java, which would be architecture specific.
> But if you want to split them into an architectur
On Sun, 12 May 2002, Egon Willighagen wrote:
> And the same for gcj? Is there an easy way to port a Ant based compilation
> to some Makefile like stuff for compiling with gcj? Is there a good tutorial
> on it somewhere?
I've got a makefile based build system, that supports jdk-like jvms(kaffe,
su
On 12 May 2002, Jim Pick wrote:
> Also, as the upstream kaffe maintainer, I'd really like it if for each
> package that was stuck in contrib because kaffe can't run it (eg.
> unimplemented APIs, etc), there was a "wishlist" bug filed against kaffe
> stating how it fails. I suppose that goes for t
On 12 May 2002, Nic Ferrier wrote:
> 2.5. Main, contrib or non-free
>
>
>
> If your binary package can run only with non-free virtual machines
> (the only free Java virtual machine seems to be kaffe - and the one
> included in libgcj), it cannot go to main. If your package itself is
>
> "Andrew" == Andrew Pimlott <[EMAIL PROTECTED]> writes:
Andrew> No it's not. But you can use the gcj produced .so files
Andrew> with gcj. If I do all my Java development with gcj,
Andrew> Debian packages containing Java libraries compiled to
Andrew> .so's are very useful to m
On Sun, May 12, 2002 at 04:28:56PM -0700, Stephen Zander wrote:
> > "Andrew" == Andrew Pimlott <[EMAIL PROTECTED]> writes:
> Andrew> To clarify, I'm talking about Java code compiled (eg, by
> Andrew> gcj) into architecture-specific machine code. These
> Andrew> libraries are still
> "Andrew" == Andrew Pimlott <[EMAIL PROTECTED]> writes:
Andrew> To clarify, I'm talking about Java code compiled (eg, by
Andrew> gcj) into architecture-specific machine code. These
Andrew> libraries are still meant to be used by Java code (also
Andrew> compiled with gcj), not
> "Egon" == Egon Willighagen <[EMAIL PROTECTED]> writes:
Egon> And the same for gcj? Is there an easy way to port a Ant based
Egon> compilation to some Makefile like stuff for compiling with gcj?
Egon> Is there a good tutorial on it somewhere?
In theory you should be able to use `gij' as a dr
On Sun, May 12, 2002 at 10:31:43PM +0200, Egon Willighagen wrote:
> On Sunday 12 May 2002 22:00, Andrew Pimlott wrote:
> > Ok, then it is just a question of naming. Say my foo library can be
> > compiled to .class files and GCJ .so files. One option is to
> > package both in libfoo-java, which wo
> On Sun, May 12, 2002 at 09:16:37PM +0200, Ola Lundqvist wrote:
> > Java code is supposed to be
> > portable. If you compile it to machine binaries it is no longer a
> > java program and should not be packaged as a such.
>
> You've been listening to too much Sun marketing. :-)
>
> Please give a
ecific it would be like stuff compiled from C.
> Thus libfoo and not libfoo-gcj-java...
I was just about to say the same. Maybe we should state in the java policy
that it incly covers packages that produces java bytecode. And that the
-java name is reserved for such packages.
> However, i
On Sunday 12 May 2002 22:00, Andrew Pimlott wrote:
> On Sun, May 12, 2002 at 09:40:05PM +0200, Ola Lundqvist wrote:
> > I disagree on that class files should be placed in a -dev package for the
> > same reason as I want every jar file to be placed in /usr/share/java
> > (maybe with an exception for
On Sun, May 12, 2002 at 09:40:05PM +0200, Ola Lundqvist wrote:
> I disagree on that class files should be placed in a -dev package for the
> same reason as I want every jar file to be placed in /usr/share/java
> (maybe with an exception for jvm:s). You should always be allowed
> to use the classes
On Sun, May 12, 2002 at 10:05:55PM +0200, Egon Willighagen wrote:
> On Sunday 12 May 2002 21:32, Ola Lundqvist wrote:
> > On Sun, May 12, 2002 at 09:13:35PM +0200, Egon Willighagen wrote:
> > > On Sunday 12 May 2002 21:11, Egon Willighagen wrote:
> > > > Only if your binary package can run with fre
On Sunday 12 May 2002 21:32, Ola Lundqvist wrote:
> On Sun, May 12, 2002 at 09:13:35PM +0200, Egon Willighagen wrote:
> > On Sunday 12 May 2002 21:11, Egon Willighagen wrote:
> > > Only if your binary package can run with free virtual machines (like
> > > kaffe, libgcj, ORP and KissMe), it may go i
On Sun, May 12, 2002 at 03:10:25PM -0400, Andrew Pimlott wrote:
> On Sun, May 12, 2002 at 09:16:37PM +0200, Ola Lundqvist wrote:
> > Java code is supposed to be
> > portable. If you compile it to machine binaries it is no longer a
> > java program and should not be packaged as a such.
>
> You've b
On Sun, May 12, 2002 at 09:13:35PM +0200, Egon Willighagen wrote:
> On Sunday 12 May 2002 21:11, Egon Willighagen wrote:
> > Only if your binary package can run with free virtual machines (like kaffe,
> > libgcj, ORP and KissMe), it may go into main. Otherwise, it must go into
> > non-free, or in c
On Sun, May 12, 2002 at 09:16:37PM +0200, Ola Lundqvist wrote:
> Java code is supposed to be
> portable. If you compile it to machine binaries it is no longer a
> java program and should not be packaged as a such.
You've been listening to too much Sun marketing. :-)
Please give a rational reason
On Sun, May 12, 2002 at 02:45:24PM -0400, Andrew Pimlott wrote:
> On Sat, May 11, 2002 at 05:41:29PM +0200, Ola Lundqvist wrote:
> > http://people.debian.org/~opal/java/policy.html/policy.html
>
> The following,
>
> Both are shipped as Java bytecode (*.class files, packaged in a
> *.jar
On Sunday 12 May 2002 21:11, Egon Willighagen wrote:
> Only if your binary package can run with free virtual machines (like kaffe,
> libgcj, ORP and KissMe), it may go into main. Otherwise, it must go into
> non-free, or in contrib if your package itself is free.
Better:
Only if your binary packa
On Sunday 12 May 2002 17:11, Nic Ferrier wrote:
> Ola Lundqvist <[EMAIL PROTECTED]> writes:
> If your binary package can run only with non-free virtual machines
> (the only free Java virtual machine seems to be kaffe - and the one
> included in libgcj), it cannot go to main. If your package i
On Sat, May 11, 2002 at 05:41:29PM +0200, Ola Lundqvist wrote:
> http://people.debian.org/~opal/java/policy.html/policy.html
The following,
Both are shipped as Java bytecode (*.class files, packaged in a
*.jar archive) and with an "Architecture: all" since Java
bytecode is supposed t
On Sun, 2002-05-12 at 08:11, Nic Ferrier wrote:
> Ola Lundqvist <[EMAIL PROTECTED]> writes:
>
> > Hi
> >
> > When we now have (almost) got woody out of the door I think it
> > is time to give the Proposed Java Policy a more official state
> > (i.
Package: java-common
Severity: normal
On Sun, May 12, 2002 at 03:11:41PM +, Nic Ferrier wrote:
> Ola Lundqvist <[EMAIL PROTECTED]> writes:
>
> > Hi
> >
> > When we now have (almost) got woody out of the door I think it
> > is time to give the Propos
Ola Lundqvist <[EMAIL PROTECTED]> writes:
> Hi
>
> When we now have (almost) got woody out of the door I think it
> is time to give the Proposed Java Policy a more official state
> (i.e. not proposed anymore).
>
> It is available at:
>
> http://people.
Hi
When we now have (almost) got woody out of the door I think it
is time to give the Proposed Java Policy a more official state
(i.e. not proposed anymore).
It is available at:
http://people.debian.org/~opal/java/policy.html/
The actual policy is avalable at:
http://people.debian.org/~opal
On Sat, Sep 15, 2001 at 01:12:43PM -0500, Adam Heath uttered:
>
> Sorry for the large cc, but it is about time that debian had a unified policy
> on these package names.
>
Right.
> On Sat, 15 Sep 2001, Ben Burton wrote:
>
> >
> > Okay. Note that java policy states
case I'm all for putting something in debian policy proper
advocating this. I personally don't care in the slightest whether it's
lib-foo-java or libfoo-java (java policy says one and perl policy says
the other; AFAIK these are the only documents where the issue is raised).
Thoug
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
58 matches
Mail list logo
