On Wed, 15 Oct 2003 18:04:32 +0200 Jan Schulz <jasc.usenet@gmx.de> wrote: > Hallo Arnaud, Hallo Jan, > * Arnaud Vandyck wrote: > >Same for me, wait until sarge is out and let's restart the discussions > >about a new policy. > > Sorry, but that was exactly the reply I was *not* hoping for. IMO > there is enough discussion and the whole thing needs some testing. I'm > also willing to write most of the initial patches. What I'm not > willing is just sit quiet until the *next* (and next...) discussion. sorry Jan ;) I agree with you but let me explain (if I have to) why I did not take part of all these discussions: - I had a lot of work at the beginning of the 'java policy' thread; - then went on holliday; - then had a lot of work (until late november!). 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, 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. > To integrate this changes would be in most cases (we don't have that > many java *apps*, but lots of libs) a > 'cp debian/package.jars debian/package/usr/share/java-config/package' > in debian/rules (or add dh_java during binary-indep). OK, it's a line change for a library, but you also have to build the .jars file to complete (also, I did not catch if there was different jar groups depending on the virtual machine?.. exemple: I don't know if all the jvm's have javax.sql.*, it's needed by libcommons-dbcp-java... and tomcat4. There was an attempt to make the javax.sql.* package also with jta (but non free) but I drop the idea because classpath project did reimplemented it... just an exemple that comes in my mind, maybe they are others). > 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 > In the apps it would be CLASSPATH="$(java-config -all $PACKAGE)", > where $PACKAGE is all converted packages (I will start with the > low-level libs and work my way up...) and adding the if .. else .. fi > block around the current 'find java'-magic. > > All this *does* *not* interfere with current policy. 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. > 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've no idea how far the sarge release is (the last bit I read said > two weeks behind), but it will take at least another two month (more > like after new year). There are several attemps to add something to > the policy in the BTS and all have died. I'm not willing to let that > happen to this attempt. > > So what I'm asking now for is either > > * Yes, I find this propsal reasonable and think it will work. I intent > to add the patches to my packages, if they don't interfere with > current policy. 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. > I intent to give up proposing this changes, if the second opinion is > consensus or if noone replys to this. > > I'm sorry to say it this hard, but IMO it does no good to say 'later' > all the time. again sorry. > Until now, there was almost no reaction form DDs and if, > the questionable points were hopefully answered or the appropriated > changes were made. What I want is some more comitment to this, so that > I see that the work on this isn't wasted. 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 ;) > And I'm also more than a bit fed up with this 'no reaction' attempt, > especially when there is almost no work doing the change or just > reading through the propsal and add a opinion. > > So, please make up your mind. 'Fed up' is hard! Jan, it's not (at least for me) an easy area and your mails (Dalibor also like the long mails ;)) are not easy to understand after a day full of work and stress (I don't tell you about my wife complaining because I read my mail :-D). I can understand it's frustrating and I have to congratulate you for your work. Make up your mind ----------------- 1° I don't think it's the better solution...; 2° ...but it seems to be a good one at the moment; 3° I don't think your proposal must be marked as 'MUST' or 'REQUIRED'; So (even if I'm not yet a DD), I second your proposal if point 3 is respected. Last thing, I did not follow _the whole_ discussion and am not completly familiar with policy changes and so on. Very last thing, I do prefer focus on more urgent things. For me, the most important thing at the moment for the debian-java community is to have gjdoc in the best shape to be able to build the javadoc with a free tool, next, ship gjdoc with kaffe (I'm helping the kaffe team but have not the time at the moment). After this major goal, I'd like to have the most free jvm and compilers in the next stable release... and in the best shape as possible. I'd like to contribute more to this thread and I hope to have an easier and more 'java oriented' solution one day. Thanks for your work Jan, and sorry to be not so responsive on this thread. Best regards, -- Arnaud
Attachment:
pgp2eeJuUu42F.pgp
Description: PGP signature