Hallo Arnaud,
* Arnaud Vandyck wrote:
>Jan Schulz <[EMAIL PROTECTED]> wrote:
>> * Arnaud Vandyck wrote:
>So I did not follow all the thread. I appreciate the summary effort and
>after reading this mail I have no special argument to stop your proposal
>but I do not want to second it if it's a MUST in the policy. You know,
I understand that the proposal, as it is, is *not* "secondable", as it
misses some testing first. Debian policy is based on 'common practise'
(which the old java policy, in most parts, was surely not), so I hope
I can implement wide parts of it before asking for a policy change.
But without any 'make it so' comments, or some of the bigger java
maintainers, which change their packages, I will not get this changes
made and so the policy will not get tested and in the end nothing
changes.
>something that makes a bug 'serious'. First I'm not yet a DD so even if
>I can make the changes soon, I'll need to ask a sponsor, I'm not sure
>when my packages will be uploaded. Second, I'm sure some DD just don't
>have the time to change all their packages.
I don't ask for a upload only for the sake of adding the changes for
the porposal. What I ask for is 'if I have to upload the apckage the
next time, this file will also be part of it'. I don't expect to file
100 wishlist bugs during the next days, but I will spread most of the
changes over the next weeks.
> OK, it's a line change for a library, but you also have to build the
> .jars file to complete
Yep: during the next requied upload.
>(also, I did not catch if there was different
> jar groups depending on the virtual machine?..
No. The java runtime requirement is 'located' in teh java apps (which
have to call 'findjava' in the starter script).
Anyway, this is a really good point, which I overlooked during teh
discussion. This will basicly mean that we can remove the
|A package must depend on the disjunction of all JVMs with
|which it has been tested succesfully.
Part from the library section. Or replace it with
|A library only package should not depend on any java virtual machine
|package.
>> For VM maintainer it will be a cp and maybe some looking into the doc
>> and adding the right flags, where I missed something.
>It seems to be really easy ;) Ean, any comment? :-D
Yes, that's also still something I waiting for :) Although I think I
will do much of the work, as I want to write the patch for mpkg-j2sdk...
>Well, if I understand, we can slowly begin the work of implementing your
>idea _without a policy change_ and when every packages does use the
>findjava wrapper a good policy text will be ready for inclusion into the
>java policy.
Thanks, thats the first time someone said this. I hope some other will
also write something along this lines.
>> But for all this I need something more than 'wait for the sarge
>> release and *restart* discussing *then*'.
>Sorry for the restart the discussion! ;)
I don't much mind the restarting but much more the 'wait until after
the discussion/...' part.
>Yes it seems resonable but I don't know if it will work on the long
>term... and I think the dependency of libraries in java is a java
>problem that must be solved in a java way: META-INF/MANIFEST.MF or
>something like this also in libraries, not only in applications. Or
>maybe an xml file or a property file in META-INF like the
>META-INF/services but I don't know this purpose very well. I'll discuss
>that with a co-worker and will try to study that in the futur weeks.
If you do this, then you should start this discussion on a sun ML, so
it is included there. But this will probably not work, as SUN will
simple refuce to accept that there are 'non licensed' JVM. And thats
the primary goal for such mechanism, for the rest it is too less
'finetuned' to make any difference.
Anyway, I think this proposal is a big difference to the 'maybe it
will start, maybe not' situation, which is currently happening, when
you don't use some special tricks (JAVA_HOME), which are undocumented
and not debian conform.
>I don't know if it's the better solution but if I'll be there to try
>your javafind package. I'll look for the informations you provide in the
>archives but once again, I'm not yet a DD and I'm very busy teaching
>java at the moment ;)
but with 15 package to change you are quite a big 'do it' opinion :)
>1° I don't think it's the better solution...;
Better to the 'best' sollution or to the current solution?
Thanks for teh reply!
Jan
--
Jan Schulz [EMAIL PROTECTED]
"Wer nicht fragt, bleibt dumm."
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
