Am Sonntag, dem 26.03.2023 um 12:15 +0300 schrieb Timo Aaltonen: > Markus Koschany kirjoitti 24.3.2023 klo 15.35: > > Am Freitag, dem 24.03.2023 um 09:21 +0200 schrieb Timo Aaltonen: > > > Markus Koschany kirjoitti 23.3.2023 klo 19.00: > > > > Control: severity -1 serious > > > > > > > > On Fri, 24 Feb 2023 11:48:36 +0200 Timo Aaltonen <tjaal...@debian.org> > > > > wrote: > > > > > > > > > Upstream doesn't support tomcat10 yet, and tomcatjss fails to build > > > > > with > > > > > it. > > > > > > > > Unfortunately we can only support one Tomcat version per release. We > > > > should > > > > either migrate to tomcat10 or maybe it is possible to embed some of the > > > > required tomcat9 classes in your source package as a workaround > > > > provided > > > > the > > > > changes are rather small and the security impact is negligible. > > > > > > Right, but that's for bookworm+1? By that time I'm sure > > > jss/tomcatjss/dogtag have gained upstream support for tomcat10. > > > > We are targeting Bookworm. We had Tomcat 8 in Stretch and Tomcat 9 in > > Buster > > and Bullseye already. Tomcat 10 also targets Java 11 and later while Tomcat > > 9 > > was intended for Java 8 and later. We ship OpenJDK 17 in Bookworm. > > resteasy3.0 > > and tomcatjss are the only packages apart from i2p that still depend on > > libtomcat9-java. > > Nice, so you expect them to migrate after bookworm is already frozen?
Targeted fixes are still allowed. Including required tomcat9 classes in your package may be a solution too. If you can find an agreement with the security and release team, then even shipping libtomcat9-java might be possible. But then your packages will not receive any security support.
signature.asc
Description: This is a digitally signed message part
