On Mon, 12 Dec 2022, Emmanuel Bourg wrote:
> There is another benefit of a versionless package: backport continuity. When
> the tomcat package replaces tomcat in testing/unstable, it's no longer
> possible to update the tomcat backport in stable (because the version must
> exist in testing). With
Le 28/09/2022 à 17:53, Emmanuel Bourg a écrit :
Pros:
- no need to create a new package, replacing tomcat with tomcat
everywhere, and then wait for the NEW queue
- unique packaging repository
- no more transition, replacing the libtomcat-java dependency with
libtomcat-java everywhere (current
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 agre
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 fo
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
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
6 matches
Mail list logo
