Simon Josefsson <simon@josefsson.org> writes:
> For those wondering how the TUFv0-vs-v2 dilemma is resolved, you may not
> want to know but here is the story:
>
> x) The problem is that cosign requires both github.com/sigstore/sigstore
> ("ss") and github.com/sigstore/sigstore-go ("ssg"), and that ss depends
> on TUFv0 and ssg depends on TUFv2, and further TUF branches are not
> released in a namespace-clean way so v0 and v2 cannot be co-installed in
> Debian.
>
> x) Upstream discussions implied that we could simply try to patch
> things, pending their upstream resolution to this (which may not happen
> until cosign v3 and I'm not holding my breath on that).
>
> x) I've uploaded golang-github-sigstore-sigstore 1.8.10-3~exp0 to
> experimental that again ships pkg/tuf/ and pkg/fulcioroots/ but patched
> to use my own invention of a github.com/theupdateframework/go-tuf/v0
> namespace from the golang-github-theupdateframework-go-tuf-dev >>
> 2.0.2+0.7.0. Any other packages that require TUFv0 will need similar
> patching, but I expect/hope this to be minimal.
>
> x) I've uploaded golang-github-theupdateframework-go-tuf 2.0.2+0.7.0-1
> to experimental that includes a new orig.tar component of the v0 0.7.0
> branch, and some patching to rename all references to
> github.com/theupdateframework/go-tuf into
> github.com/theupdateframework/go-tuf/v0 when building the v0 component,
> and bringing back some old debian/copyright and build magic from the
> earlier TUF 0.6.1-1 upload.
>
> Better solutions are welcome! I'm hoping github.com/sigstore/sigstore
> will drop the TUFv0 dependency, or that github.com/sigstore/cosign will
> drop the github.com/sigstore/sigstore dependency, so that we can drop
> this ugly hack, and hopefully do that before trixie.
I have uploaded golang-github-theupdateframework-go-tuf into unstable.
Once TUF 2.0.2+0.7.0 migrates to testing, I'll upload
golang-github-sigstore-sigstore too.
Both build fine in my pipelines, including rebuild of reverse build
dependencies:
https://salsa.debian.org/jas/golang-github-theupdateframework-go-tuf/-/pipelines/778446
https://salsa.debian.org/jas/golang-github-sigstore-sigstore/-/pipelines/778472
The dependency computation here is interesting, as it is cyclic. It
seems that for TUF 'build-rdeps' cuts the list after sigstore-sigstore,
and not adding packages that depend on TUF that are behind
sigstore-sigstore, which seems like a bug. However those packages are
tested in the sigstore-sigstore pipeline above. I don't know how to
avoid the cyclic loop, it is due to upstream.
The podman rebuild failure does not seem related to this package, and it
happens natively for podman too. The singularity-container package is
already known FTBFS.
If someone understands how to write a debian/watch file that tracks the
two independent orig.tar components (see debian/README.source), and/or
how to get gbp-export-orig to re-create the orig.tar as two separate
components, that would be a nice improvement. But it is feasible to
manage this manually.
/Simon
Attachment:
signature.asc
Description: PGP signature