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.

I suppose there is some established pattern for this, but I cannot
recall it right now.  I tried comparing jwt vs jwt-v5 but upstream
cleanly uses different namespaces, so no problem there.  Is there some
other Go packages to compare?  Guidance appreciated.

Of course, packaging v2 as a separate package may have been a mistake,
but I don't see a better way to provide the old v0 library and the new
v2 library.  Is there something upstream could do to help?  Had they
used a new namespace (like jwt v5) this wouldn't be a problem.

/Simon

Simon Josefsson <[email protected]> writes:

> Package: wnpp
> Severity: wishlist
> Owner: Simon Josefsson <[email protected]>
>
> * Package name    : golang-github-theupdateframework-go-tuf-v2
>   Version         : 2.0.2-1
>   Upstream Author : The Update Framework (TUF)
> * URL             : https://github.com/theupdateframework/go-tuf
> * License         : Apache-2.0
>   Programming Lang: Go
>   Description     : Go implementation of The Update Framework (TUF)
>
>  The Update Framework (TUF) helps developers maintain the security of software
>  update systems, providing protection even against attackers that compromise
>  the repository or signing keys. TUF provides a flexible framework and
>  specification that developers can adopt into any software update system.
>
> I hope to maintain this package as part of Debian Go Packaging Team:
>
> https://salsa.debian.org/go-team/packages/golang-github-theupdateframework-go-tuf-v2
>
> The current Debian package golang-github-theupdateframework-go-tuf is
> for the old v0.x API, quoting upstream:
>
>  The legacy go-tuf (v0.7.0) (https://github.com/theupdateframework/go-
>  tuf/tree/v0.7.0) codebase was difficult to maintain and prone to errors
>  due to its initial design decisions. Now it is considered deprecated in
>  favour of go-tuf v2 (originaly from rdimitrov/go-tuf-metadata
>  (https://github.com/rdimitrov/go-tuf-metadata)) which started from the
>  idea of providing a Go implementation of TUF that is heavily influenced
>  by the design decisions made in python-tuf
>  (https://github.com/theupdateframework/python-tuf).
>
> Indeed, I tried rebuilding the reverse dependencies of this package with
> v2.x and while most packages actually built, there are some that fails
> due to TUF v0 vs v2:
>
> https://salsa.debian.org/jas/golang-github-theupdateframework-go-tuf/-/pipelines/751423
>
> Since the package has a different license and looks like a complete
> rewrite to me, I think it makes sense to have two separate Debian
> packages for it.
>
> /Simon
>

Attachment: signature.asc
Description: PGP signature

Reply via email to