Re: [PROPOSAL] 3. RfD on new debian java policy
Hallo Jan,
--- Jan Schulz <jasc.usenet@gmx.de> wrote:
> >I think it would be a good idea to set some sort of policy for this. See
> >e.g. the two different gjdoc packages (gjdoc and gjdoc-native). Why have
> >the gjdoc version that depends on byte code when there is already a
> >normal native application?
>
> Becasue the gjdocs package will do the job fast than the native
> compiled gjdoc? I don't want to start a flamewar, and I haven't looked
> into this *at all* (only seen a discussion about some benchmarks,
> which said, that IBM java is faster than gcj).
I don't think benchmarks are very useful in the context of picking VMs for
debian, with debian being a cross-architecture linux platform. kaffe, for
example, is infinitely many times faster than IBM's VM on debian's superh
platform, because there is no port of IBM's VM for superh-linux, as far as I
know. What do we learn from this factlet? Not much, I think.
> >> >> 2.1. Java virtual machines and runtime environments
> >> Maybe the java policy should link to a file, which holds the current
> >> state of this virtual packages.
> >But that means that this definition is completely useless for Debian
> >developers since there are no packages in Debian that satisfy this
> >definition.
>
> There isn't such a package in debian. But if we want our users to be
> able to use Sun/IBM virtual maschines, this should be made possible
> via this interface.
Then it doesn't really belong in a debian java policy, does it? Into some
debian java faq maybe, but placing requirements on maintainers to ensure
interoperability with some proprietary package sounds a little far fetched.
While I have no doubt that you're motivated enough to make sure that the
eclipse package works with non-free VMs, I doubt that other package maintainers
should have to follow your lead to make sure their packages work with something
that is not part of debian anyway.
To make things somewhat clearer: I have no problem with your own debian
non-free VM interface being defined in some debian non-free java faq, and you
using it. In fact, I like some of your ideas, and think they can be used to
improve debian's support for free java environments. But I have a problem with
your non-free interface being a part of an official debian policy and requiring
other maintainers to care about non-free VMs that are not part of debian. That
places unreasonable burden on those maintainers, like installing non-free VMs
and accepting their licenses, which violate DFSG.
> I have no idea, how far you've looked into the current implemntation
> to make this possible, so I just give you some of my impressions, from
> packaging eclipse.
> * Eclipse wasn't yet able to run with free JVM (kaffee 1.1.1 might
> change that, but I haven't looked into that. gij is not AFAIK (yet))
It still won't run without problems with kaffe 1.1.1. Things may be better with
kaffe 1.1.2, wait and you shall see. Or even better, check out kaffe from CVS,
hop on kaffe's mailing list and give us some tips on what you need fixed ;)
I've seen eclipse run nicely with gij from CVS a few weeks ago.
>
> >> 5. Programs That Don't Meet Our Free-Software Standards
> >> |We acknowledge that some of our users require the use of programs
> >> |that don't conform to the Debian Free Software Guidelines. [...]
> >> |Thus, although non-free software isn't a part of Debian, we support
> >> |its use, [...]
> >That says Debian acknowledges the existince of such software (a sad fact
> >that cannot be denied), but it doesn't say that Debian should promote
> >and advertise such things. And this unfree interface isn't even part of
> >contrib or non-free.
>
> The 'unfree interface' is a way to access unfree JVM. It's also a
> attempt to seperate 'incomplete' (spec and API wise) JVM from complete
> ones.
You still haven't defined a measure for completeness, that can be applied to
sepearate incomplete JVMs from complete ones. Handwaving as in 'it should run
every java application' is not a good measure. I can provide you with examples
where sun's VM can't work reliably, because the API spec itself is sometimes,
frankly, quite bad.
I don't care much about an unfree interface for unfree VMs, but I care about
the free ones being labelled as 'incomplete' without having a chance to compete
with the non-free ones on the same playground. That's basically like saying
free java VMs all suck, but not saying why, and keeping the bar raised just
above their heads all the time. I don't think debian users or developers would
be served well by a policy that scares users away from free java VMs
> Debian policy is a document, which describes debian packages and how
> to create them. It does not promote anything. Getting a unfree VM
> working with the packaging system *still* requires more steps than the
> normal 'apt-get install <javaapp>'. Unfree JVM *are* able to run our
> packages and they are 'free as in beer' for our users.
If I understood your proposal correctly, it forces maintainers to make their
packages depend on some non-free vm interface. I think that's a bad idea.
> I will neither propose nor agree with a debian java policy, which will
> ignore this facts and make out users patch debian packages to get this
> working.
It's all fine and well as long as other debian maintainers don't have to depend
on non-free VMs if they don't need to. If some other debian developers want to
support non-free VMs in their packages, why not. But to require that other
debian developers go out on a limb to support non-free software is a little bit
too much of catering to non-free software to be codified as a debian policy.
why stop there? why don't you require that all free debian VM packages written
in C and C++ should be buildable with non-free tools, like intel's C/C++
compiler? I'm sure some people would like to rebuild their VM packages to get
some perceived benefits from using a proprietary, non-free compiler tool, so
why don't we mandate that while we're at it?
> >> This will give packages the chance to supply specific comandlien
> >> arguments for each regular packaged JVM and use the unfree interface.
> >> This should be 'good enough'.
> >What do you mean 'good enough'? Good enough for what?
> >If you insist on things supporting this unfree interface you should at
> >least give a good definition of it in the policy so packagers can make
> >sure they have implemented it correctly.
>
> I think we can rely on sun, that a given version of a JVM will be
> complient with the original sun one. The only 'requirement' about the
> 'bin/java unfree interface' is a alternative for /usr/bin/java-version.
You say 'specific command line arguments' but you don't specify them. then in
the next paragraph you say that nothing is required in the interface beside
some packaging alternative stuff. I think there is a contradiction here
somewhere: either you require a well-defined set of command line switches with
well-defined semantics, or you don't really have an interface. ;)
> >> >> 2.2.1. Ant Environment
> >> As I said: patching this task in ant isn't an easy sollution, as it
> >> probably needs a complete rewrite.
> >I don't think this will be that hard. But then again I am not a Ant
> >hacker.
>
> I think I could get that going in some afternoons, but it would mean
> that someone with insight into the different javadoc implemenations
> needs to do the delegates. And that all means that we will introduce
> some code, which will have bugs, which is not complient with the nomal
> ant and so on. This changes should be done upstream, they are to big
> to be handled as debian patches. And a 'debian branch' isn't that nice
> as well.
>
> Please also note, that I currently don't have this 'some afternoons'.
I think it would be great if more people would volunterr to fix such design
defects in ant, but I don't think that you have to do everything yourself ;)
I'd imagine that ant developers who wrote the javadoc task would welcome
suggestions to improve the code, and if you can get them, or the developers of
javadoc replacement tools to work out the code, you don't have to write it
yourself ;)
I have found ant developers to be in general quite responsive to my attempts to
get ant to run on top of kaffe.
> >> I think the easiest would be to say that the requirement to supply a
> >> 'ant environment' would be to run succesfully a test suite.
> >> Unfortunatelly, there is currently no javadoc testcase in the ant
> >> package :(
> >A test-suite would be ideal!
>
> I will try to see what we can do about this. In the moment this is low
> priority for me.
ant comes with its own set of regression tests. I don't know how much they
test, though.
> >Then why still have the /usr/bin/javac alternative?
>
> Because of backward compatibility (at least until the transition to a
> new policy is over). Because some suers expect to see a /usr/bin/javac
> command. and this is certainly good enough for HelloWorld.java. just
> not enough for programms like tomcat or eclipse.
I thought eclipse used its own java compiler and didn't care about
/usr/bin/javac?
> >> So they are normal native apps as handled by the normal debian policy.
> >> This is the debian *Java* policy.
> >Then what precisely is the goal of the *Java* policy?
>
> To deal with java apps/libs, which comes precompiled into java byte
> code.
What about apps/libs, that are part compiled bytecode, part something else?
Think about jython applications, for example.
> >They should get the upstreeam sources in that case and
> >hack on those.
>
> I'm not going to punish someone, because he has a requrement for a
> unfree piece of software. Neither by forcing this user to download a
> bunch of package to satisfy dependencies, which are actually satisfied
> by the unfree piece of software, nor by making him to compile software
> 'the hard way', when this software is available by the debian
> packaging system.
How do you want to provide the unfree VMs if you don't force the user to
download a bunch of packages? Should they be linked into the kernel? ;)
I don't see what is so hard about installing kaffe, or sable VM, or whatever
other free VM to build a package if the maintainer says that the build will
work with it. there is nothing hard about it, if it's in the requirements to
build the thing. The 'hard way' is to make the maintainer also work out a way
to build the package with non-free VMs using the 'non-free interface' in
addition to a sane way to build the package with free VMs.
the same argument could be also waged against all packages using ant to build:
they could equally well use make, but they instead chose to make life hard for
make users to build the software by not providing makefiles. Let's file bug
reports till we all feel better about it, yay ;)
cheers,
dalibor topic
__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com
Reply to: