Thanks for feedback! I'll try to cancel the -v2 NEW upload, and will do a v2 upload to experimental to allow others to help test. I did upgrade the old package and did a reverse rebuild, see pipeline here:
https://salsa.debian.org/jas/golang-github-theupdateframework-go-tuf/-/pipelines/751423 The libpod failure is unrelated and a known FTBFS, so this leaves two packages: golang-github-sigstore-sigstore and rekor, both packages I'm familiar with. There are TUF-related build failures here, which is why I gave up and started on the v2 approach. Rekor fails to build with TUF v2: https://salsa.debian.org/jas/golang-github-theupdateframework-go-tuf/-/jobs/6475597 src/github.com/sigstore/rekor/pkg/pki/tuf/tuf.go:33:2: cannot find package "github.com/theupdateframework/go-tuf/data" in any of: src/github.com/sigstore/rekor/pkg/pki/tuf/tuf.go:34:2: cannot find package "github.com/theupdateframework/go-tuf/pkg/keys" in any of: src/github.com/sigstore/rekor/pkg/pki/tuf/tuf.go:35:2: cannot find package "github.com/theupdateframework/go-tuf/verify" in any of: src/github.com/sigstore/rekor/pkg/types/tuf/v0.0.1/entry.go:37:2: cannot find package "github.com/theupdateframework/go-tuf/pkg/deprecat I've opened an upstream issue about upgrading TUF from v0 to v2 in rekor: https://github.com/sigstore/rekor/issues/2256 The build errors in sigstore-sigstore looks similar: src/github.com/sigstore/sigstore/pkg/tuf/client.go:37:2: cannot find package "github.com/theupdateframework/go-tuf/client" in any of: src/github.com/sigstore/sigstore/pkg/tuf/client.go:38:2: cannot find package "github.com/theupdateframework/go-tuf/client/leveldbstore" in any of: src/github.com/sigstore/sigstore/pkg/tuf/client.go:39:2: cannot find package "github.com/theupdateframework/go-tuf/data" in any of: src/github.com/sigstore/sigstore/pkg/tuf/client.go:40:2: cannot find package "github.com/theupdateframework/go-tuf/util" in any of: I opened an upstream issue about this too: https://github.com/sigstore/sigstore/issues/1871 In the best of worlds, upstream will provide a patch and new release shortly, or at least a patch that applies to our current release. In the worst of worlds, upstream won't do anything -- is there any good way out of that situation? Could we patch packages so the TUF package can provide both v0 and v2? Any documented mechanisms, or existing packages to look at? Realistically, I suspect things will take time and eventually rekor/sigstore-sigstore will be modified to use TUF v2. Meanwhile this means packages that needs TUF v2 can only go to experimental, right? Not ideal, but still better than nothing. If you or anyone think the v2 approach is still relevant, we can consider that too, but I think your advice to avoid that route is good. /Simon Reinhard Tartler <siret...@gmail.com> writes: > Thinking out aloud: What's the value of having a -v2 package that is not > co-installable? > Every package build needs to pick a single version, and I'm concerned that > this will > make the transition unnecessarily hard. We had a similar situation with > protobuf, and > it took us literally years to untangle those conflicts. > > Have you considered simply updating > the golang-github-theupdateframework-go-tuf package in > experimental and migrating all dependencies? How many packages are we > talking about and > what packages need (non-trivial) porting? > > $ siretart@x1:~ $ build-rdeps golang-github-theupdateframework-go-tuf-dev > [...] > Reverse Build-depends in testing/main: > -------------------------------------- > > golang-github-containers-buildah > golang-github-containers-common > golang-github-containers-image > golang-github-crc-org-crc > golang-github-sigstore-fulcio > golang-github-sigstore-sigstore > golang-github-sylabs-sif > oci-seccomp-bpf-hook > podman > rekor > skopeo > > Looking at the packages "golang-github-containers-buildah", it doesn't look > like they have code > that interacts with tuf directly, but pull that in indirectly via sigstore. > I haven't checked the other > packages, but I honestly think the number of packages here might be small > enough that introducing a -v2 > package is not worth the trouble. > > I'm asking to make sure that we are understanding the trade-offs and making > good decisions here.
signature.asc
Description: PGP signature
