Path: csiph.com!news.mixmin.net!aioe.org!bofh.it!news.nic.it!robomod
From: Markus Koschany <apo@debian.org>
Newsgroups: linux.debian.maint.java
Subject: Re: Tomcat 10 packaging
Date: Thu, 29 Sep 2022 15:10:01 +0200
Message-ID: <Fb1sB-aT3G-13@gated-at.bofh.it>
References: <FaHNf-aH6g-13@gated-at.bofh.it>
Old-Return-Path: <apo@debian.org>
Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="=-Ln9QNcZUne8N21xznTIY"
MIME-Version: 1.0
Approved: robomod@news.nic.it
Lines: 126
Organization: linux.* mail to news gateway
Sender: robomod@news.nic.it
Xref: csiph.com linux.debian.maint.java:12449


--=-Ln9QNcZUne8N21xznTIY
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi,

Am Mittwoch, dem 28.09.2022 um 17:53 +0200 schrieb Emmanuel Bourg:
> Hi all,
>=20
> For Debian Bookworm I'd like to replace Tomcat 9 with Tomcat 10. But=20
> this time instead of introducing a "tomcat10" package, I wonder if we=20
> could instead create a version-less "tomcat" package and keep it for the=
=20
> next major releases.

Thanks for starting this thread. I wanted to update src:tomcat10 and packag=
e
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 separa=
tion
between different major Tomcat version has been useful so far because there
always was a clear expectation when users installed a versioned tomcat pack=
age
for a stable release. There is strong demand for security support for Tomca=
t 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>=
=20
> everywhere, and then wait for the NEW queue
> - unique packaging repository
> - no more transition, replacing the libtomcat<n>-java dependency with=20
> libtomcat<n+1>-java everywhere (currently about 15 packages)
> - no need to install tomcat<n+1> and transfer /etc/tomcat<n> to=20
> /etc/tomcat<n+1> when upgrading Debian
> - the log files and the deployed web applications also remain at the=20
> same place

While less packaging work is always a plus, I don't mind copy and pasting t=
he
existing debian sources. Also the wait in the NEW queue is rather negligibl=
e if
the upload is done way ahead of the stable freeze as it was done with Tomca=
t
10. There are often breaking changes between major Tomcat versions and user=
s
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 f=
ind
two tomcat packages in unstable or at least experimental very useful. You a=
lso
have to keep in mind that Ubuntu and other distributions just copy the pack=
age
and release more frequently. With a versionless tomcat package it could eas=
ily
happen that there are major regressions in between two Debian stable releas=
es
which would directly hit Ubuntu and co users because they release more ofte=
n.
While we would fix those bugs in unstable eventually, other users had to de=
al
with those issues in a stable release. A sudden and automatic upgrade from =
9.x
to 10.x may be surprising for them.

>=20
> Cons:
> - the unique repository will probably have multiple upstream branches=20
> when Tomcat upgrades are uploaded to oldstable as part of the LTS, this=
=20
> may be tricky with gbp
> - if the new configuration files are incompatible with the previous=20
> format, upgrading Debian may break the Tomcat instance. Either it no=20
> longer starts, or some configuration elements or features no longer=20
> work. With separate packages, the system upgrade is unlikely to break=20
> Tomcat, but the user may forget to upgrade it and will keep an=20
> unsupported instance that is no longer receiving security updates.
>=20
> 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 w=
hich
always points to the latest major Tomcat version in Debian. Thus we could a=
void
updating our r-deps for every new release, similar how we deal with the JDK=
.

Regards,

Markus


--=-Ln9QNcZUne8N21xznTIY
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----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-----

--=-Ln9QNcZUne8N21xznTIY--