Path: csiph.com!news.mixmin.net!aioe.org!bofh.it!news.nic.it!robomod
From: Emmanuel Bourg <ebourg@apache.org>
Newsgroups: linux.debian.maint.java
Subject: Re: Tomcat 10 packaging
Date: Fri, 30 Sep 2022 12:00:01 +0200
Message-ID: <FbkYh-b4pW-1@gated-at.bofh.it>
References: <FaHNf-aH6g-13@gated-at.bofh.it> <Fb1sB-aT3G-13@gated-at.bofh.it>
Old-Return-Path: <ebourg@apache.org>
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.13.1
Content-Language: en-US
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Approved: robomod@news.nic.it
Lines: 60
Organization: linux.* mail to news gateway
Sender: robomod@news.nic.it
Xref: csiph.com linux.debian.maint.java:12452

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