Hi, Am Mittwoch, dem 28.09.2022 um 17:53 +0200 schrieb Emmanuel Bourg: > Hi all, > > For Debian Bookworm I'd like to replace Tomcat 9 with Tomcat 10. But > this time instead of introducing a "tomcat10" package, I wonder if we > could instead create a version-less "tomcat" package and keep it for the > next major releases. Thanks for starting this thread. I wanted to update src:tomcat10 and package the latest upstream release. https://tracker.debian.org/pkg/tomcat10 I am not totally against creating a new versionless src:tomcat package but I wonder if we should delay this idea for Debian 13. In my opinion the separation between different major Tomcat version has been useful so far because there always was a clear expectation when users installed a versioned tomcat package for a stable release. There is strong demand for security support for Tomcat in LTS and even ELTS, so this would be a change which we should be especially careful about. > Pros: > - no need to create a new package, replacing tomcat<n> with tomcat<n+1> > everywhere, and then wait for the NEW queue > - unique packaging repository > - no more transition, replacing the libtomcat<n>-java dependency with > libtomcat<n+1>-java everywhere (currently about 15 packages) > - no need to install tomcat<n+1> and transfer /etc/tomcat<n> to > /etc/tomcat<n+1> when upgrading Debian > - the log files and the deployed web applications also remain at the > same place While less packaging work is always a plus, I don't mind copy and pasting the existing debian sources. Also the wait in the NEW queue is rather negligible if the upload is done way ahead of the stable freeze as it was done with Tomcat 10. There are often breaking changes between major Tomcat versions and users can't expect that their applications will seamlessly work when they upgrade their tomcat packages to newer major releases. So this is a point where I find two tomcat packages in unstable or at least experimental very useful. You also have to keep in mind that Ubuntu and other distributions just copy the package and release more frequently. With a versionless tomcat package it could easily happen that there are major regressions in between two Debian stable releases which would directly hit Ubuntu and co users because they release more often. While we would fix those bugs in unstable eventually, other users had to deal with those issues in a stable release. A sudden and automatic upgrade from 9.x to 10.x may be surprising for them. > > Cons: > - the unique repository will probably have multiple upstream branches > when Tomcat upgrades are uploaded to oldstable as part of the LTS, this > may be tricky with gbp > - if the new configuration files are incompatible with the previous > format, upgrading Debian may break the Tomcat instance. Either it no > longer starts, or some configuration elements or features no longer > work. With separate packages, the system upgrade is unlikely to break > Tomcat, but the user may forget to upgrade it and will keep an > unsupported instance that is no longer receiving security updates. > > What do you think? At the moment I would play it safe for Debian 12 and go with src:tomcat10. However we could think about introducing a libtomcat-default-java package which always points to the latest major Tomcat version in Debian. Thus we could avoid updating our r-deps for every new release, similar how we deal with the JDK. Regards, Markus
Attachment:
signature.asc
Description: This is a digitally signed message part