Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.debian.maint.java > #12452

Re: Tomcat 10 packaging

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

Show all headers | View raw


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 | NextPrevious in thread | Next in thread | Find similar


Thread

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