Re: [PROPOSAL] New Virtual Packages and way to handle Classpath
Hallo Jan,
--- Jan Schulz <jasc.usenet@gmx.de> wrote:
> Hallo Dalibor,
>
> * Dalibor Topic wrote:
> I wanted to say, that you have a interface for the 'unfree' ones and
> this interface will work, even if you have 'not working' JVM
> installed. The current interface (/usr/bin/java) does not garantee,
> that your package is working.
I don't think that an 'interface' can guarantee that a package is working with
a specific VM environment. Only testing by the üackagers and users can
guarantee that.
> >I'm sorry, but I don't see how that will help free java in debian. It
> >may get more bug reports submitted to kaffe & co, and make releases
> >take longer because all of that has to be sifted through, bit it won't
> >really help.
>
> What do you expect? This policy is about packaging java apps/libs/jvm in
> debian. It can include some items to make porting the app to a free VM
> easier (which could be done by simple adding a alternative for the
> required 'unfree interface' and then start testing), but this si IMO
> not the primary goal.
>From debian I'd expect a policy that helps and guides java apps/libs/jvm
maintainers to build and package their stuff with a focus on free VMs, gives
pointers who to get in topuch with if things don't work, has a section on free
java developers working on providing a free java infrastructure and how to
contribute to it, and provides the necessary bits of information on how to
deal with the legacy, proprietary VMs. Certainly not the other way round ;)
> So what interface do you propose? I think that adding something to the
> ant-build-compiler interface or even making it
> ant-build-compiler-version would solve most of this.
I haven't thought about an ant build interface yet. I think it should mostly
concern itself with setting a few ant properties, like 'build.compiler' to try
to ensure that ant works with a particular VM environment, instead of relying
on sun-centric defaults provided by ant.
> >I think that codifying a status quo is such a good idea. It makes the policy
> >obsolete quite quickly. I'd prefer a policy that tells maintainers to
> >explicitely tells maintainers to test their packages with free VMs and mark
> >those that work.
>
> And what's the difference with my proposal? The only thing is, that
> policy can't tell mainatiner something, just how you package has to be.
Sorry, then I must have misunderstood. I thought your policy proposal defined
some 'java-xy compatible interfaces' that java packages should use, where the
interfaces are losely defined to match Sun's, in hope that this would make an
application work on all three non-free VMs and maybe even on free ones, should
they ever achieve some undefined form of java-xy compatibiliy. Instead, my
proposal is to drop the notion of compatibility, and have the maintainer put
down what VM environments work, and depend on any one of them being installed.
> The current 'policy interface' (/usr/bin/java, etc) is just to less to
> work. But IMO, we can't simple start a policy, which requires every
> small thing or this policy will be longer than the complete debian
> policy...
Uh, I'm not saying that the current debian java policy is all that great. I
applaud your effort so far, to get debian java developers to re-think debian
support for java and to revise the policy. It has been a very educational
experience for me ;)
cheers,
dalibor topic
__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com
Reply to: