Stephen Kitt <skitt@debian.org> writes: > Hi Simon, > > On Mon, 03 Nov 2025 08:19:48 +0100, Simon Josefsson <simon@josefsson.org> > wrote: >> I uploaded golang-golang-x-mod to unstable now, having had success >> uploading golang-golang-x-sys and migrating it (which seems like a >> similar package as golang-golang-x-mod with many reverse dependencies). > > It’s an easy mistake to make since in both projects, gbp.conf doesn’t specify > upstream tags, but the Salsa projects for x-mod and x-sys track upstream > commits; the latest bumps imported the upstream changes as a single commit. > > Does anyone know if there’s a reason not to set this up in gbp.conf? That is a general question I have about Go packaging -- some Go projects seems to import upstream source code via git fetch <up> gbp import-orig --sign-tags --uscan --upstream-vcs-tag=<commit-ish> and some packages via gbp import-orig --sign-tags --uscan where the first one seems to pull in all commits since the last release, and the second one pulls in the latest release as one commit. Is specifying which behaviour to enforce in gbp.conf even possible? Doesn't it depend on what the commands the maintainer run? How to convey the intention for each project? How to make tooling yell at the maintainer to not do the wrong thing? Does any linter notice this? Personally, I have been doing 'gbp import-orig --sign-tags --uscan' since a long time (before Go team) and I only lately learned that --upstream-vcs-tag=<commit> ends up making the Salsa history different. I thought they were essentially equivalent. With the --upstream-vcs-tag style, 'gbp dch -R --commit' ends up adding all upstream commit messages to debian/changelog though, so I found this approach difficult to use. Do others see that? I'm using git-buildpackage version 0.9.25, maybe this is fixed in later versions. I've long given up trying to enforce a particular style across packages, but I think it make sense to continue use the same style within a package [although sometimes it makes sense to migrate to some newer pattern]. I didn't notice I made this mistake for these two packages, sorry about that. /Simon
Attachment:
signature.asc
Description: PGP signature