[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

golang-github-theupdateframework-go-tuf migration



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 <simon@josefsson.org> writes:

> Package: wnpp
> Severity: wishlist
> Owner: Simon Josefsson <simon@josefsson.org>
>
> * 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 to: