All,
I've uploaded the v2 package to NEW and it builds fine and seems to
work.
But how do we handle migrations for packages that use the same
namespace? Now both golang-github-theupdateframework-go-tuf and
golang-github-theupdateframework-go-tuf-v2 will provide some overlapping
files, so cannot be co-installed. That is okay, I guess, but lead to
problem in a package that depends on two different dependent packages,
one that may (eventually) depend on v2 and one that (eventually) depend
on non-v2. Maybe all involved packages could be upgraded to v2, but it
may be that some dependency that require the new library and some really
require the old one.
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.