"Dr. Tobias Quathamer" <[email protected]> writes: > Am 14.02.26 um 18:26 schrieb Simon Josefsson: >> We have discussed golang-github-jackc-pgx v5 before: >> >> https://lists.debian.org/debian-go/2025/01/msg00023.html >> >> Did you try upgrading the existing golang-github-jackc-pgx to v5 and >> rebuild reverse dependencies? They are very few (compared to other >> recent migrations) and looks feasible to complete. >> >> /Simon > > Hi Simon, > > I've created a new source and binary package, using the -v5 suffix. This > way, there's no need to check all reverse dependencies, because the > package with v4 is still available. However, packages needing the v5 of > golang-github-jackc-pgx can just Build-Depend on the newly uploaded package. > > From what I understand, the "v{digit}" convention in go is used to > signal a (possibly) breaking change in the package's API. Therefore, I > think it's sensible to create a new package for such version suffixes > instead of trying to update an existing package. > > If I'm not mistaken, both v4 and v5 could even be installed at the same > time without file conflicts. But I don't think this is a realistic > scenario, because those golang-*-dev packages are normally only used for > building other golang packages.
Right -- we've discussed this a couple of times on debian-go@ (cc'ed) and I think there are concerns with introducing new packages for latest version of packages, and my interpretation of the opinions is to prefer this: 1) Try to update to latest version, patching reverse dependencies and reporting upstream bugs requesting that. 2) Upload to current version as golang-github-jackc-pgx-v4 and migrate all dependencies that cannot be upgraded to it, and then update golang-github-jackc-pgx to v5. 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. 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. 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. 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. /Simon
signature.asc
Description: PGP signature
