Re: Tomcat 10 packaging
Le 29/09/2022 à 15:06, Markus Koschany a écrit :
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.
I agree, it's nice to ease the packaging work, but the deciding factor
should be the user experience.
Currently, upgrading Tomcat in Debian consist in:
- install tomcat<n+1>
- move the content of /var/lib/tomcat<n> to /var/lib/tomcat<n+1>
(especially the lib directory containing the JDBC drivers)
- move the log files from /var/log/tomcat<n> to /var/log/tomcat<n+1>
- copy and adapt the configuration files from /etc/tomcat<n> to
/etc/tomcat<n+1>
- uninstall tomcat<n>
A unique package would reduce this procedure to the configuration update
step.
The same result could be achieved by having versioned packages
conflicting with each other. For example tomcat10 would use versionless
paths (/etc/tomcat, /var/lib/tomcat, /var/log/tomcat), and installing
tomcat11 would trigger the removal of tomcat10, while reusing the same
paths.
On the packaging side, we could mimic the openjdk package and generate
the versioned packaging files automatically.
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.
It's interesting to consider the Debian derivatives side. For Ubuntu I
don't think this will change the situation that much. They already apply
their own security fixes anyway since their stable Tomcat versions
aren't aligned with ours. And major updates in Debian won't trigger a
major update in the stable Ubuntu releases.
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.
The default libtomcat-java package is a good idea.
Thank you for sharing your thoughts!
Emmanuel Bourg
Reply to: