>From the above and a separate mail thread also involving glassfish, I
gather these are the points various comments refer to - please correct
me if I miss anything:
1. Missing binary dependencies: should have dependency on the package
"java2-runtime" and optionally suggest sun-java5-jre | sun-java6-jre |
icedtea-java7-jre | openjdk-6-jre ?
2. Java library packages should be called (e.g) "libsun-javadb-core-java"
(dashes acceptable?).
==> must the binary package be split if it contains not only jars, but also
has e.g [platform independent] user utilities in ./bin? (concerned, since this
would break 1:1 package mapping across platforms) It looks like NB6 has done
this, but cannot check details at the moment.
3. Java libraries (class files in jars) should be in /usr/share/java, one for
each jar the product/package delivers, e.g
[libsunjavadb[-client]] -> lib[sun-javadb][-client]-[fullversion].jar
==> would also need /usr/share/javadb/lib/derbyclient.jar soft link to one
of these to not break default user utilities in /usr/share/javadb/bin,
documentation and demos, and avoid causing general confusion among "veteran"
Java DB/Apache Derby users and deployers.
==> how should all these lib*-<fullversion> jars be shipped and maintained?
must all be included in later packages? should upgrade of the lib*-java
package not uninstall the old versioned jars while installing the new versioned
jars? Or would I *have* to use the package name construct libXXX[version]-java
for this, e.g to keep Java DB 10.3 and 10.4 jars apart? - could be a lot,
should there be a need for many [fullversion] bug fix releases - and how should
these be phased out?
==> http://www.us.debian.org/doc/packaging-manuals/java-policy/x105.html is
not consistent in its use of package and jar file versions: fullversion or
version? E.g for Java DB fullversion = 10.3.2.1, but the "compatibility"
(functionally equivalent) version would be 10.3 (which first came with
10.3.1.4).
Please also note:
a. comment 3) under http://revu.tauware.de/details.py?upid=1972: Java
DB is a rebranded distribution of Apache Derby and brings the unmodified
binaries from Derby, in the customary Derby layout. (which would put it
in multiverse)
b. Java DB is not just a library, it is a full-featured database.
c. The DLJ license does explicitly NOT prohibit the exclusion of the Java DB
bits (in the db/ subdir) from sun-java6:
http://download.java.net/dlj/jdk6/README.html#redistribution. sun-java6-javadb
could be dropped altogether, and the corresponding bits ship with another
package.
sun-javadb should replace the sun-java6-javadb package in multiverse (which
breaks all items 1-3 above). They are the same thing, but only the former will
update in synch with the Apache Derby community releases and that co-packaged
with Sun's JDK releases. The latter is a remnant of a quick integration of the
DLJ JDK bundle for Feisty.
--
FeatureFreeze exception request for sun-javadb
https://bugs.launchpad.net/bugs/192887
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
