Hallo Stefan, * Stefan Gybas wrote: >You are a package manager, not a "standard" user. You should have a lot >of differnt JDK installed anyway to be ably to very bug reports so >what's the problem with on specific JDK in build dependencies?
Almost half of the bugs/mails about eclipse ended in the user using backports... Eclipse is using c libs, is in contrib (only i386), so this are reasons to compile yourself... >There's no need to backport (pure) java packages, I have tomcat4 with >all its dependecies from sid running fine on woody. Me too. But I was fed up doing manual downloads and dpkg -i, so I use apt-get source and a local repository... >>have javac1.3 and 1.4). And IBM javac *should* be the same as BD, >>eclipse.org (jdtc), jikes or sun. If not, its a bug. >They are not. Have a lot of fun filing all those bug reports, I have >given up and use what upstream uses. I might be a happy packager, because the eclipse compiler (available as jdtc) which is actually used to develop eclipse, is quite good and complient to all other big java compilers (they get bugreports every time it doesn't fit with jikes or javac :). It's also build with IBM1.3 (win, linux) and Sun1.3 JDKs (solaris), so this will catch most of the problems. >For example libpgjava will build a different driver when building with >JDK 1.3 (JDBC 2.0) or JDK 1.4 (JDBC 2.0 with standard externsions). The >same is true for Tomcat4, it will enable addition features when built >using JDK 1.4. I don't so much mind if I can only use a 'greater as' compiler, but I mind if I can only use the sun compiler. IMO this should be reported upstream. >If you are absolutely sure that you gat the same results with JDK 1.3 >and JDK 1.4 you can use either. But why wasting your time with bug >reports like "upstream works, Debian package does not" when you can >simply use the same setup as upstream does? Up to now I had one bugreport about this but two about 'why does alian j2sdk*rpm' does not satisfy my (Build-)Depends:. For me it took more time to answer and explain this to the user, than fixing the 'JAVA_HOME line or getting the backport for the 'works with 1.3, but not with 1.4' fix. >I know, I even have it installed. But you said it was not working with >IBM's JDK so I was looking for a better alternative. It's not working, because the latest IBM comes as tar.gz instead of a -bin. I will try to get a patch together for this and send it upstream. Don't know when I have time for this, though... >If you want the >standard mpkg-j2sdk in java-common please file a bug report. Wasn't tora waiting for some upstream rewrite before uploading (as a seperate package)? I wouldn't mind, if java-common then recomends or depends on it. >>liblog4j1.2-java and liblog4j1.1-java. >What happens when they are both included in the class path like in the >scenario that I have described in my previous mail? They shouldn't. Thats also why I 'invented' the '*jars' system for eclipse. Anyway, in case of one jar, it should be enought to -cp log4j1.1.jar or -cp log4j1.2.jar Where the version number is the same as the package version number (think: the same API). >Good idea. Let's see how well this works for other packages like JAXP >compliant XML parsers. Do you have time to test this? Not until next week (exams)... What do you want? I've currently the mentioned eclipse xerces (XML4j) lying around here. Is that such a JAXP XML Parser? Unfortunatelly JAXP seems rather a bad example: If I see this right, you need a new package name every new release as it always *breaks* something?! >Again, what do you want to do when you need to add two conflicting JARs? I what cases? 1) Xerces2.x and Xerces2.y -> two packages which are name with the API version and and which have jars with this api versions append to the name xerces2.4-java: xercesImpl-2.4.jar xml-apis-2.4.jar (NO symlink to xercesImpl or xml-apis jar) xerces2.4-java.jars: JARS=/usr/share/java/xercesImpl-2.4.jar:/usr/share/java/xml-apis-2.4.jar after next *breaking* API change xerces2.5-java: xercesImpl-2.5.jar xml-apis-2.5.jar (NO symlink to xercesImpl or xml-apis jar) xerces2.5-java.jars: # could included by a dh_ script: JARS="/usr/share/java/xercesImpl-2.5.jar:/usr/share/java/xml-apis-2.5.jar" DEPENDS="" # from 'Depends: *-java' CONTRIBUTES-TO="" application Depends: on xerces2.5-java: application.jars: JARS="/usr/share/app/app-helper.jar" DEPENDS="xerces2.5-java, .. , .." CONTRIBUTES-TO="" /usr/bin/app: ... # Where getJavaClasspath is a script which returns *all* needed jars # to run this library/package, including recursive needed libs CLASSPATH=$(getJavaClasspath "application"); ... 2) Two packages, which provides the same API (SWT, IBM|Apache Xerces). -> Use a virtual package (versioned), on which the app should depend on and the virtual-package-java.jars file will be set via update-alternative. By using the right jars file, the classpath should work out. >... without the infrastructure (ldconfig, dpkg-shlibdeps, ...) but the >the same problems as C libraries (conflicting libraries linked in one >application). I must say, that I don't have that many knowledge about c libs (I read about the shlibs in policy and found it quite practically), so I can't really comment on the 'the same problems'. What are they? For the infrastructure: This shouldn't be the problem: We don't have to deal with 'runtime' loading, just with adding something 'shortly before runtime'. Plugins should be done anyway with seperate dirs and classloader (that's at least my experience with eclipse, which has all its jars in a different folder(s)). This could be dealt with specifying a 'dir' instead of a jar (simple traversing like ant does it now) or letting the 'getJavaClasspath' skript figure that out (With for example a CONTRIBUTING-TO="ant" and a update-javeclasspath skript in post(rm|inst). I'm not a good shell skripter and at least the update-* should be done in perl, but IMO I could hack a prototype together in about an afternoon. No dpkg-shlibs equivalent, thats true, but IMO thats anyway not possible, because of 'compiletime=runtime'-lib (no -dev packages) and we surely can't hack a compiler together, which will add this on-the-fly.... But for this being usefull, it needs to be policy the same way as shlibs is policy and helper scripts (dh_*, CDBS). What also needs to be done is stricter use of versioned packages. And new virtual packages for JVM1.(3|4|..), Javac(..), JavaAPIClasses1.(3|4) (CLASSPATH together with Kaffe is the same as Sun JDK?), Mozilla-Plugin(|c102). And then mpkg-j2sdk should Provides: all the right things, when used with a '-bin' download. This (after a little more though than 2 mintues :) should ensure, that java, with all the nonfree JVM, is fiting a little better in the famose debian package system... Anyway, I wouldn't mind doing the runtime things and the *.jars buildtime creating (dh_jars or whatever). If it can take another week... And after some more discussion here... :) 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]