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
Hi Markus,
Thank you for taking care of the upgrade. I have no objection to push
the packaging changes to the next Debian release. Bug 965006 happened
because I forgot to update the Maven rules, if the 9->10 substitution is
done well the tomcat10 package will be co-installable with tomcat9.
Hi all,
I would like to upload tomcat10 to unstable and discontinue tomcat9 for the
upcoming next stable release.
https://tracker.debian.org/pkg/tomcat10
I don't intend to introduce any of the changes we have previously discussed on
this list for now and just move on with the usual modifications
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
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-les
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
8 matches
Mail list logo