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.

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

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?

Emmanuel Bourg

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 9/28/22 17:53, Emmanuel Bourg wrote:

- 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

Just set debian-branch & upstream-branch accordingly in debian/gbp.conf.

See for example:


https://salsa.debian.org/debian-gis-team/postgis/-/blob/apt.postgresql.org/postgis-2.5/debian/gbp.conf

Kind Regards,

Bas

--
GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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


-----BEGIN PGP SIGNATURE-----

iQKTBAABCgB9FiEErPPQiO8y7e9qGoNf2a0UuVE7UeQFAmM1mFJfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEFD RjNEMDg4RUYzMkVERUY2QTFBODM1RkQ5QUQxNEI5NTEzQjUxRTQACgkQ2a0UuVE7 UeSidw/9EiizDw64FhwbHX1WF2Qj4FpFLAj8gQs7/oJTS46W+b3LS51KtL+AVyxE XTzW+5okGAhGdIJ5miUJvHrlIbTjNG6/53oCxrfn2Co6aZXZbxGusQcwn6TEiJvV GN4+XQhc8yWTqybfdfOStd2JCjyBKmJfDItzmbnFw27R3fS7an63cibxXCyyqP5X h0okf6Xb3D0GWg/rBPp3pITlFnJXqxnZmGWLcOSIbkxIH25amu7sronSpiucqvRZ dzoU5yQVFRwjoYUAsFUD9lutB3qqu8p6+V8eCsfh7w+2qyYf4wjfE6iRpV9wCt2h OVQOQg7ekrtYbj93aeaZJPeKw724+WJQAL3A6BFXjQphywL4Oitrp4M5Ghl0XgA+ jQaAZgmSVy4J6OumZ7iqeSfPIwR17sUo9gkrAFYL2pONOliodvRMQeNTNQM3XCEt aiMdRDgGAanYTWiPTFS9y8Z6uG1QDscs1fKw4nlUdmFS94cNYRZGxTPbB+njbRDb k2YOgkHB68Vh114uyFtSIaQiM6ckyoHque6XxyDPz4XBpjZl9bwny/qLZ6nT6rmS yXFhBV6L/gf67UCgyzooZiIuH5gREbuKgL5N4XNVt9Ip53EIcGblzvbcUbd07kZz ox8917SuFoAygqVjDJfovED2rCJJ1dIL1/KRY6Z4jTjE7LBtR5E=
=8+5R
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Le 28/09/2022 à 17:53, Emmanuel Bourg a écrit :

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

There is another benefit of a versionless package: backport continuity.
When the tomcat<n+1> package replaces tomcat<n> in testing/unstable,
it's no longer possible to update the tomcat<n> backport in stable
(because the version must exist in testing). With a unique tomcat
package we can keep updating the stable backport even after upgrading to
a more recent release in testing.

(this is just a note for later discussions)

Emmanuel Bourg

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Mon, 12 Dec 2022, Emmanuel Bourg wrote:

There is another benefit of a versionless package: backport continuity. When the tomcat<n+1> package replaces tomcat<n> in testing/unstable, it's no longer
possible to update the tomcat<n> backport in stable (because the version must exist in testing). With a unique tomcat package we can keep updating the stable
backport even after upgrading to a more recent release in testing.

Downside: no tomcat<n> update for stable users any more, they will be
forced to tomcat<n+1> prematurely.

It might be possible to get a backport exception and/or keep <n> in
testing until just before the release to ease this.

bye,
//mirabilos
--
Infrastrukturexperte • tarent solutions GmbH
Am Dickobskreuz 10, D-53121 Bonn • http://www.tarent.de/
Telephon +49 228 54881-393 • Fax: +49 228 54881-235
HRB AG Bonn 5168 • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

**************************************************** /⁀\ The UTF-8 Ribbon
╲ ╱ Campaign against Mit dem tarent-Newsletter nichts mehr verpassen:  ╳  HTML eMail! Also, https://www.tarent.de/newsletter
╱ ╲ header encryption!
****************************************************

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)