Hi,
On 2022-03-02 17:24, Markus Koschany wrote:
(Speaking about tomcat10, I noted the package in experimental is really
old - doesn't seem to have been updated for a few years. Do you know if
anyone is working on updating the package to e.g. Tomcat 10.0.17 or will
it perhaps happen later in the Bookworm release cycle?)
I intend to update it in the near future. I believe the initial goal was to
make it co-installable with Tomcat 9. Currently there are still some file
conflicts which have to be resolved before we can upload Tomcat 10 to unstable.
Aha, I see. Good to know.
We still need OpenJDK 8 to bootstrap Kotlin. Please don't ask for its removal.
It would be great if we could use OpenJDK 11 instead but we are not there yet.
Alright, I will definitely not suggest it in that case. :D
As for the actual libeclipse-jdt-core-java package, is there any
particular reason for going with the 4.21 version in Debian unstable &
bookworm? I am just curious. It feels like a somewhat odd decision to go
with a more recent version than the 4.20 version which Apache bundles in
their distribution. But perhaps there are other Debian packages which
can find use of the newer package, or has it perhaps just been done to
be able to ship the "latest and greatest" version of this package with
Bookworm? (I mean: to not ship something which is "old" already at the
time of release.)
I guess there was no particular reason other than upgrading to the latest
available version back then. I have not investigated yet if another Debian
package requires 4.21 specifically but since we don't really support Java 8
anymore I think we can just move forward. Tomcat 9 will be gone next year and
since we rather have to invest time into fixing OpenJDK 17 bugs than making
packages Java 8 compatible, I would say let's keep it as is.
Thanks, I'm fine with this. I suggest we keep this bug open until we
have the Dependencies line for tomcat9 fixed, as discussed.
For our own internal needs, we'll have to find another approach (either
creating our own tomcat9 package as you suggested, or spending the time
getting our software to be ready for Java 11 (and eventually Java 17) -
or both. :-)
Given that we will likely have to spend quite an effort moving from
tomcat9 to tomcat10 (because of the javax.* to jakarta.* package
change), providing this as a package of our own might not be such a bad
idea anyway, since it gives us total control of when to roll it our to
our customers. (We have built an in-house product which is deployed
using Tomcat at a number of on-premise & cloud-based installations, so
being too dependent on the Tomcat version which happens to be in Debian
unstable => Ubuntu LTS at any given time is perhaps not ideal for us.)
Best regards,
Per
