Reinhard Tartler <siretart@gmail.com> writes: > Hi Simon, > > I really don't see a way around getting through the NEW queue and > introducing a new source package here. > > Since golang-github-cenkalti-backoff is already at v5 in experimental, I > suggest we package v4 as src:golang-github-cenkalti-backoff-v4 which > produces golang-github-cenkalti-backoff-v4-dev. > > This -v4 package would then live in unstable side-by-side with the v5 code > in the existing binary packages. This will break existing packages, which > will need to be fixed by either porting them to v5, or updating > debian/control to build against golang-github-cenkalti-backoff-v4-dev. > > This approach is very similar to the common practice in Rust. Yes, I agree this make sense. However: how to handle file conflicts? Both packages will provide /usr/share/gocode/src/github.com/cenkalti/backoff/backoff.go wouldn't they? The packages could Conflict with each other, but I don't think that will fly: I'm sure some package will end up recursively depending on both. How about putting the golang-github-cenkalti-backoff-v4-dev files into /usr/share/gocode/src/github.com/cenkalti/backoff/v4/backoff.go and then, for all packages without upstream v5 support, update build-depends to golang-github-cenkalti-backoff-v4-dev and add a patch that changes which namespace to use? "Martin Dosch" <martin@mdosch.de> writes: > Hi Simon, > > if it is such a big diff maybe package it as it were a new library and > add a -v5 suffix? > Not elegant, but then v4 and v5 would be available. This is the simplest path forward, but it becomes really ugly when a v6 comes out. I think the "right" package name should be reserved for the latest upstream version, and that we introduce a new v4 package and patch all consumers is better. Otto Kekäläinen <otto@debian.org> writes: >> Since golang-github-cenkalti-backoff is already at v5 in >> experimental, I suggest we package v4 as >> src:golang-github-cenkalti-backoff-v4 which produces >> golang-github-cenkalti-backoff-v4-dev. >> >> This -v4 package would then live in unstable side-by-side with the >> v5 code in the existing binary packages. This will break existing >> packages, which will need to be fixed by either porting them to v5, >> or updating debian/control to build against >> golang-github-cenkalti-backoff-v4-dev. > > Even though this is a bit painful, I still think it is the best thing > to do. The package name that is "versionless" should be reserved for > the latest version, and if older versions are needed to be kept > around, they should have the version suffix. Great, we have some agreement on this then. >>From the Salsa CI reverse builds dep job you shared I can see these > are failing. Seems indeed majority (but not all) are failing on > dependency on cenkalti/backoff/v4. Many of the packages are already > using v5 upstream and would be fixed by simply updating the package, > but not all. If there is only a small number of packages, that could be done at once: I just did a small transition of golang-github-ccoveille-go-safecast via experimental that required new uploads of golang-github-tillitis-tkeyclient and golang-github-smallstep-certificates which I staged in experimental for testing. But for golang-github-cenkalti-backoff-dev I'm not sure this is feasible. Trying to update all packages and moving them into experimental will take time, and stop progress for all involved packages until the transition is over. I'm not sure I can commit to finishing this in a timely fashion, nor is that a good expectation to have for contributions IMHO. I think we agree that uploading a v4 package allows simple and safe migration strategies. It seems a bit wasteful to introduce a NEW package which eventually will fade away, just to do a transition, but I think the alternatives are worse. > build-rdep-deck 1.4.0 from 2021 (latest 1.54) > build-rdep-docker.io 27.5.1 (latest 29.1.2, upstream has v5 already in > build-rdep-gh 2.46.0 from January 2025 (latest 2.83) > build-rdep-golang-github-lestrrat-go-backoff 2.0.8 from 2021 (upstream > build-rdep-golang-github-maxmind-geoipupdate 6.1.0 from March 2025 > build-rdep-golang-github-ovn-org-libovsdb 0.8.1 from Oct 2025 > build-rdep-golang-github-r3labs-sse 2.10 from Feb 2025 (upstream dead) > build-rdep-golang-github-xenolf-lego 4.9.1 from 2023 (latest 4.29.0) > build-rdep-golang-github-zorkian-go-datadog-api > build-rdep-golang-gvisor-gvisor > build-rdep-golang-opentelemetry-otel > build-rdep-gost > build-rdep-incus > build-rdep-prometheus-alertmanager > build-rdep-prometheus-sql-exporter > build-rdep-restic 0.18.1 (upstream still using v4) > build-rdep-vuls Thank you for going through these! I became exhausted just looking at the list. I'll wrap up a v4 source package and upload to NEW queue, we can sort out the file conflicts later. /Simon
Attachment:
signature.asc
Description: PGP signature