Stephane Bortzmeyer <[EMAIL PROTECTED]> writes:
> Another reason is the lack of standards in the way compilers and VMs
> are run, making the installation of every new jar a problem (defining
> environment variables, etc). The proposed Java policy tried to solve
> this and I would suggest that work
Stephane Bortzmeyer <[EMAIL PROTECTED]> writes:
> Another reason is the lack of standards in the way compilers and VMs
> are run, making the installation of every new jar a problem (defining
> environment variables, etc). The proposed Java policy tried to solve
> this and I would suggest that wor
Aaron Brashears <[EMAIL PROTECTED]> writes:
> After some reflection it seems that it would make more sense to just
> copy the class files in /usr/share/java so setting the classpath for
> standard packages would be handled once by setting
> CLASSPATH=/usr/share/java once instead of having to tack
Aaron Brashears <[EMAIL PROTECTED]> writes:
> After some reflection it seems that it would make more sense to just
> copy the class files in /usr/share/java so setting the classpath for
> standard packages would be handled once by setting
> CLASSPATH=/usr/share/java once instead of having to tack
Stephane Bortzmeyer <[EMAIL PROTECTED]> writes:
> A sort of automake for Debian/Java? Nice idea but which has implications
> upstream.
I suppose the ideal thing to do would be to have the GNU coding
standards updated to address the issues re. installing Java programs,
and to change automake to i
Stephane Bortzmeyer <[EMAIL PROTECTED]> writes:
> > Some standard would be helpful to assist in debian packaging, e.g.
> > standard configure directives to specify repository vs. jar place, or
> > standard install targets. What would make it easy?
>
> Please be more specific because the policy a
Stephane Bortzmeyer <[EMAIL PROTECTED]> writes:
> A sort of automake for Debian/Java? Nice idea but which has implications upstream.
I suppose the ideal thing to do would be to have the GNU coding
standards updated to address the issues re. installing Java programs,
and to change automake to imp
Stephane Bortzmeyer <[EMAIL PROTECTED]> writes:
> > Some standard would be helpful to assist in debian packaging, e.g.
> > standard configure directives to specify repository vs. jar place, or
> > standard install targets. What would make it easy?
>
> Please be more specific because the policy
Packaging Debian software for Java is still somewhat confusing for me,
and policy seems to be in flux. Perhaps it would be a better strategy
for me to make BRL and Kawa trivial to package for someone experienced,
and then get a current debian developer to adopt them.
Some standard would be helpfu
Packaging Debian software for Java is still somewhat confusing for me,
and policy seems to be in flux. Perhaps it would be a better strategy
for me to make BRL and Kawa trivial to package for someone experienced,
and then get a current debian developer to adopt them.
Some standard would be helpf
It occurs to me that making any such policy work will be a real pain for
you or whoever does it if the "make install" targets of the upstream
packages want to use ${datadir}/java as the top of the repository.
This may be a better question for GNU than for Debian. Should we move
the discussion to
It occurs to me that making any such policy work will be a real pain for
you or whoever does it if the "make install" targets of the upstream
packages want to use ${datadir}/java as the top of the repository.
This may be a better question for GNU than for Debian. Should we move
the discussion to
Stephane Bortzmeyer <[EMAIL PROTECTED]> writes:
> If we had a policy which meets a rough consensus, you could tell him
> "Because it is The Policy" :-)
Consensus among whom? Do Debian developers who don't care about Java
have to be involved, or can it just be those on the debian-java list.
I'm
Stephane Bortzmeyer <[EMAIL PROTECTED]> writes:
> If we had a policy which meets a rough consensus, you could tell him
> "Because it is The Policy" :-)
Consensus among whom? Do Debian developers who don't care about Java
have to be involved, or can it just be those on the debian-java list.
I'm
Stephane Bortzmeyer <[EMAIL PROTECTED]> writes:
> Because you need a place to put the jars, too (for people who prefer
> them). If we choose your proposal, jars will be directly in the root
> of Java classes.
Is this a conflict? Foo.jar will never be a top-level directory of the
Java classes.
>
Stephane Bortzmeyer <[EMAIL PROTECTED]> writes:
> Because you need a place to put the jars, too (for people who prefer
> them). If we choose your proposal, jars will be directly in the root
> of Java classes.
Is this a conflict? Foo.jar will never be a top-level directory of the
Java classes.
I'm looking at the proposed Java policy.
http://www.debian.org/~bortz/Java/policy.html
Why would anyone have a problem with /usr/share/java being the
repository. Having a "repository" subdirectory doesn't do much to keep
/usr/share/java clean, especially if lots of apps put jar files there.
It
I'm looking at the proposed Java policy.
http://www.debian.org/~bortz/Java/policy.html
Why would anyone have a problem with /usr/share/java being the
repository. Having a "repository" subdirectory doesn't do much to keep
/usr/share/java clean, especially if lots of apps put jar files there.
It
18 matches
Mail list logo
