"Dr. Tobias Quathamer" <[email protected]> writes: > [ I'm dropping the ITP bug from CC ] > > > Am 14.02.26 um 21:28 schrieb Simon Josefsson: >> The motivation is that whenever v6 comes around, what would you do? >> Upgrade golang-github-jackc-pgx-v5 to hold v6? That would be really >> confusing. > > Sure, that would be confusing and wouldn't make sense. I wouldn't do that. > > My understanding is that golang-github-jackc-pgx-v5 will stay at v5 of > that package forever. > > If upstream releases v6 of their package, we would introduce a new > package, called golang-github-jackc-pgx-v6.
And v7, v8, ...? That is a lot of new packages, for something where we ideally would ever ship only the latest version of a package. >> Thus it seems better for golang-github-jackc-pgx to track latest >> upstream version, and if there are packages in Debian that cannot be >> upgraded, then package golang-github-jackc-pgx-vX for the earlier >> version, and migrate the broken packages to it. We went through this >> recently. > > Well, that's also possible. However, I think the approach with using an > explicit "-vX" suffix on the source package name is better, because it > stays in sync with the name of the binary package. > > Also, if I understand it correctly, it's more or less the same amount of > work -- just the other way round, right? Either we create a new package > with -v5, or we update the existing (versionless > golang-github-jackc-pgx) package to v5 and introduce a -v4 package for > the remaining reverse dependencies which cannot be upgraded yet. Yes, that is probably why that approach has been used a couple of times in the past. However, I think the problem is when future new version appears, then we are looking at exploding the number of packages. If we keep golang-github-jackc-pgx for latest upstream, and the occasional golang-github-jackc-pgx-vX for old versions when there is no feasible way to upgrade some dependent package, the total number of packages are reduced over time. >> For cases where there is only one or very few packages that is stuck on >> an old version, I think it is reasonable to consider somehow vendoring >> files and/or shipping both version somehow. It is ugly though. > > Yes, that's not ideal, I agree. That can be avoided by using -v4 and -v5 > packages, respectively. The packages which are stuck on the previous > version of a golang library can just Build-Depend on the -v4 package. Right. Or just upgrade to latest upstream version -- like Mathias Gibbens implemented for https://tracker.debian.org/pkg/golang-github-lestrrat-go-jwx which was in a similar situation. See essentially the same discussion here: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1121273 >> Is it possible to establish any concensus on this? >> >> Alas it seems the consensus process for the Go team to make updates to >> the Go Team Policy is dysfunctional. > > Hm, I think we're getting started having a discussion on this list and > share ideas. Maybe we get a consensus. :-) What do others think? Can we reach some consensus on a general recommendation on this topic? /Simon
signature.asc
Description: PGP signature
