All, Does anyone have any suggestion how to proceed here? We have github.com/cenkalti/backoff v4 in forky, and that package is not many lines of code. We have V5 in experimental, but it breaks almost all of our packages: https://salsa.debian.org/jas/golang-github-cenkalti-backoff/-/pipelines/949165 Is it feasible to get all of those packages updated to v5? The API differences seems complicated, and I definitely not feel up to patching code here. Proper backoff algorithm handling may be rather sensitive. Could we add another orig.tar component (or just vendor them) with the v5 sources, and expose that under a different name (maybe just /usr/.../github.com/cenkalti/backoff/v5?) and patch all packages that requires the v5 API to use that namespace? The difference between v4 and v5 is ~1000 lines of code. In the bug report below I say 'sbctl' but it is really 'golang-github-transparency-dev-tessera' which has ITP https://bugs.debian.org/1102648 that needs v5. It is targetting experimental now, but eventually we want that in unstable. Another idea is to patch 'golang-github-transparency-dev-tessera' to use the v4 API. But doing that feels backwards. /Simon Simon Josefsson <simon@josefsson.org> writes: > Package: golang-github-cenkalti-backoff > Version: 4.3.0-1 > > Hi! It would be nice to get v5 into unstable, 'sbctl' depends on that. > I uploaded 5.0.3 to experimental, but testing suggests it breaks most > reverse build dependencies: > > https://salsa.debian.org/jas/golang-github-cenkalti-backoff/-/pipelines/949165 > > Maybe v4 could be split off into a new source package, and those > packages that still need it could depend on that? > > Or this package becomes a v4+v5 package somehow, which I find a bit > ugly, but may be a simpler way forward. We are talking about <1000 > lines of code, most of it self-tests and license boiler plate. > > Thoughts? > > /Simon >
Attachment:
signature.asc
Description: PGP signature