Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.debian.maint.java > #12452
| From | Emmanuel Bourg <ebourg@apache.org> |
|---|---|
| Newsgroups | linux.debian.maint.java |
| Subject | Re: Tomcat 10 packaging |
| Date | 2022-09-30 12:00 +0200 |
| Message-ID | <FbkYh-b4pW-1@gated-at.bofh.it> (permalink) |
| References | <FaHNf-aH6g-13@gated-at.bofh.it> <Fb1sB-aT3G-13@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
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
Back to linux.debian.maint.java | Previous | Next — Previous in thread | Next in thread | Find similar
Tomcat 10 packaging Emmanuel Bourg <ebourg@apache.org> - 2022-09-28 18:10 +0200
Re: Tomcat 10 packaging Sebastiaan Couwenberg <sebastic@xs4all.nl> - 2022-09-28 18:40 +0200
Re: Tomcat 10 packaging Markus Koschany <apo@debian.org> - 2022-09-29 15:10 +0200
Re: Tomcat 10 packaging Emmanuel Bourg <ebourg@apache.org> - 2022-09-30 12:00 +0200
Re: Tomcat 10 packaging Emmanuel Bourg <ebourg@apache.org> - 2022-12-12 14:20 +0100
Re: Tomcat 10 packaging Thorsten Glaser <t.glaser@tarent.de> - 2022-12-12 20:20 +0100
csiph-web