Hey Simon, thanks for taking a look at the tuf package in Debian,
On Wed, Oct 23, 2024 at 5:01 AM Simon Josefsson <si...@josefsson.org> wrote:
> 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.
--
regards,
Reinhard
