Re: Java Policy Question
On Friday 10 September 1999, at 10 h 2, the keyboard of David Warnock
<david@sundayta.co.uk> wrote:
> a) often need newer versions than have been packaged eg we had problems
> with jdk1.1.7 and are now using jdk1.1.7b which is not packaged in
> potato.
IMHO, this should be a bug/wishlist against the jdk1.1 package. The maintainer
is quite overloaded but reads and processes the bugs.
Otherwise, there is nothing wrong in taking the Debian source, merging it with
the new JDK, dpkg-buildpackage it and install it. I do it sometimes when I
think that a Debian package is too old, but I don't want to loose the
advantages of the packaging system.
You'll find often such UNOFFICIAL packages here:
http://www.internatif.org/bortzmeyer/debian/apt-sources/
> b) need multiple versions of java installed eg v1.1.7 and v1.2pre2 and
> need to switch between these for different projects (also when upgrading
> a product from 1.1.7 to 1.2 we need to support both for a while).
jdk1.1 and the old jdk1.0 were installable simultaneously. Certainly, if
someone packages v1.2preX, he'll take care of that. Any volunteer? Again, a
bug/wishlist against jdk1.1 seems reasonable.
> I wonder if a package implementing java-virtual-machine (and also for
> the classpath package I have seen discussed) could be provided that does
It exists: java-virtual-machine-dummy. Its main purpose is to deal with
non-Policy compliant VMs. In the future, it will disappear, as soon as
everyone is compliant.
A more general solution to this common problem is the "equivs" package. Take
the potato version, the slink one is really buggy.
> I appreciate that our need as java developers is different from people
> who use java applications which is I think the original focus for the
> policy.
No, no, the policy targets both of them.
Reply to: