Re: [PROPOSAL] New Virtual Packages and way to handle Classpath
Hallo Dalibor,
* Dalibor Topic wrote:
>I sense a contradiction here. Either the interface is meant for non-compliant
>free VMs as well, then the first paragraph is weird, or the free VMs will be
>handled separately, but then there is no interface, so the second paragraph is,
>huh, weird ;)
Aem, yes...
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.
>> Debian has a reputation, that it works. Not that the users are the beta
>> testers.
>Then tell me, how does having an interface that noone implemented make things
>magically work?
I will send a patch to the mpkg-j2sdk upstream mainatainer after this
Proposal is a bit more official and ready to be worked on. I will also
change eclipse to use it. I will also try to make much of this as easy
as possible by coding the dh_java debhelper, which will generate much
of the required files
We (debian java mainatainer) are a relative small group and it should
be possible to first have a Proposal accepted and then do the work.
>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.
>Here's another one: you'll have to keep updating that interface with every new
>release of Sun's VM, because they add things here, and break things there. If
thats why I sayd nothing about the 'unfree' interface, but just about
the '/usr/bin/java' interface (which should not be used by packages).
I expect that IBM, SUN and BD JVM of a certain version will be so
much the same, that we can't get it better with some debian java policy
requirements.
>you feel like having the next discussion on the virtues of adding a
>way to select a compiler that supports the assert keyword for packages
>that may use that, then why stop there? You may also want to consider
>adding a switch to the interface to make sure compilers generate the
>code in a compatible byte code format with the VM the code is supposed
>to run on. Sun has changed the byte code format as well between
>releases, so code built with jikes 1.18, for example, may not run on
>some VMs. And so on: next year, when java 1.5 somes out, sun will be
>adding a few more changes to the language, like generics. You'll need
>to take care of that, too ...
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 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.
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...
Jan
--
Jan Schulz jasc@gmx.net
"Wer nicht fragt, bleibt dumm."
Reply to: