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
>