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."
