Append +ds suffix to upstream version when repacking

[aviralgarg05]

Description

This PR resolves the issue where the upstream version/tag used in the initial packaging was not aligned with the debian/watch file expectations when repacking is involved.

Previously, dh-make-golang would correctly configure debian/watch with repacksuffix=+ds1 if it detected that vendor directories or Godeps needed to be removed. However, the initial package version (used for the .orig.tar name and the first debian/changelog entry) did not include this suffix, leading to a mismatch that caused issues for tools like uscan and gbp.

Changes:

• Modified make.go to append the +ds1 suffix to the upstream version whenever repacking is detected (len(u.vendorDirs) > 0 || u.hasGodeps).
• This ensures that:
  • The generated orig tarball name follows the pattern package_version+ds1.orig.tar.xz.
  • The debian/changelog entry starts with version+ds1-1.
  • The debian/watch file (which expects +ds1 for repacked tarballs) is perfectly aligned with the package state.

Related Issue

Fixes #141

Verification Performed

• Unit Tests: Ran go test ./... and confirmed all tests pass.
• Build: Successfully built the tool using go build.
• Linting/Formatting:
  • Validated code with go vet ./....
  • Ensured compliance with project style using gofmt -s.
• Logic Verification: Confirmed that the u.version modification happens after the upstream source analysis but before the Git repository and template generation, ensuring the correct version propagates to all generated files.

Checklist

• Code follows the style of the project.
• Tests have been run and pass.
• No unrelated files were modified.
• Branch pushed: fix-issue-141-version-alignment

[ottok]

It is not evident to me why len(u.vendorDirs) > 0 || u.hasGodeps means that repackaging is in progress. How can dh-make-golang even know something will be repackaged as when it runs no debian/copyright with Files-Excluded exists yet at that point in time?

Note: Git commit does not follow project conventions, you could just write Append +ds1 suffix to upstream version when repacking.

[umlaeute]

isn't the suggested suffix (as per lintian) for repacking just +ds (without any repacking version)?

note that i have no clue about team policy here, so please disregard my comment if it is off.

[aviralgarg05]

Thanks for the reviews!

Logic and Timing
The reason for checking len(u.vendorDirs) > 0 || u.hasGodeps here is that dh-make-golang automatically populates the Files-Excluded field in the generated debian/copyright whenever these directories are found. Since the tool is responsible for creating these templates, it effectively initiates the repackaging process. Adding the suffix at this stage ensures that the d/changelog, d/watch, and d/copyright files are consistent from the start.

Suffix Convention
I will update the code to use the standard +ds suffix instead of +ds1 to align with Lintian recommendations and common Debian practice.

Commit Message
I will also rebase and update the commit message to follow the project convention

[ottok]

Thanks for the explanation about vendorDirs referring to upstream vendor/ and it being automatically excluded. The PR description is very extensive, but there is no inline comment at all. Perhaps something should be mentioned there as at least for me just seeing the variable name alone wasn't self-explanatory.

The repackaged suffix does not seem to be defined in the Debian Policy. Both the Developers Reference and the uscan man page mention +dfsg. I didn't spot where the uscan default value for that suffix is defined in WatchSoruce.pm, but based on packaging e.g. Godot last year I seems uscan defaults to +ds by default currently.

[aviralgarg05]

Thanks for the explanation about vendorDirs referring to upstream vendor/ and it being automatically excluded. The PR description is very extensive, but there is no inline comment at all. Perhaps something should be mentioned there as at least for me just seeing the variable name alone wasn't self-explanatory.

The repackaged suffix does not seem to be defined in the Debian Policy. Both the Developers Reference and the uscan man page mention +dfsg. I didn't spot where the uscan default value for that suffix is defined in WatchSoruce.pm, but based on packaging e.g. Godot last year I seems uscan defaults to +ds by default currently.

Thanks for the detailed review!

1. I've added the inline comment to make.go explaining the purpose of vendorDirs.
2. I've updated the PR title and description to refer to +ds instead of +ds1, aligning with the implementation and standard uscan defaults.

Ready for another look.

[n-peugnet]

isn't the suggested suffix (as per lintian) for repacking just +ds (without any repacking version)?

What lintian tag are you referring to exactly? At least the man page for debian-watch(5) indicates this:

"+dfsg" or "+ds" or "+repack" are the common values used here (sometime followed by a digit).

So the digit is not that strange. I think this digit can help in more complex packages, to indicate that the repacked tarball has changed when e.g. more files have been removed from it. This is uncommon and maybe not that important, but I don't think this digit hurts and I think it is better to not change something for no reason.

Otherwise great addition to dh-make-golang, I've been bitten by this already.

[umlaeute]

What lintian tag are you referring to exactly?

i guess anticipated-repack-count (it speaks mostly about +dfsg rather than +ds, so I might have misremembered)

[aviralgarg05]

Reverted back to the correct one!

[ottok]

Reverted back to the correct one!

There is no clear "correct" one. It is true that +ds with a digit allow one to release version such as 1.2.3+ds1-1 and 1.2.3+ds2-1 but it is very rare to make mistakes in repackaging that went all the way into an upload, and even so one can always release 1.2.3+ds-1 and 1.2.3+ds2-1. Sometimes less is more and +ds better and cleaner. Anyway, my point was that this isn't defined in the policy and there is no "correct", we can choose here whichever we think makes sense for dh-make-golang to automatically do for new packages.

[n-peugnet]

I do not have any strong opinion, I was simply against changing something for no reason. In this case the Lintian tag anticipated-repack-count mentioned by @umlaeute is quite explicit, so I think we'd better follow its advice.

[ottok]

@aviralgarg05 I advertised this on the mailing list https://lists.debian.org/debian-go/2026/02/msg00097.html to get more opinions so we can finalize and merge this. Meanwhile, if you have time, please consider reviewing other open PRs by other people so to motivate them to review yours. Thanks!

[ottok]

After thinking about this and re-reading the comments above, I think we should not have the digit and thus probably the optimal is to have +ds as the suffix?

[ottok]

I was planning to merge this now, but in addition to the actual commit it has an extra merge commit. Can you rebase on latest 'master' or do you want me to merge this manually?

[guillemj]

I think using +ds1 as default is better, it's just one more digit, and makes any potential repackaging bump uniform. This does not need to be a mistake, it can well be due to not needing vendored modules anymore for example, because they have been uploaded as separate packages.

[guillemj]

It also maps to other similar version designators where we do not start them w/o any version, but with 1, such as +nmu1, or +b1 or similar, which means having a uniform generic pattern means less rules to have to explain or remember, and thus more consistent overall versioning behavior.

[ottok]

As discussed above, there is always also a Debian revision, so having extra digit is not necessary. E.g. after version 1.0.0+ds-1 you will have 1.0.0+ds-2. To me having 1.0.0+ds1-1 you will have 1.0.0+ds2-2 would be just cluttering.

[guillemj]

They are different things, one is the upstream marker the other the packaging revision after a repack iteration the revision gets reset, from 1.0.0+ds1-1 you'd go into 1.0.0+ds2-1 (not -2). If I saw a revision skip I'd wonder what happened here, and I'd be prompted to try to check the BTS or git history, which in this case would be useless, and inconclusive.

This goes back to avoiding to use strange and non-uniform versioning schemes, which either need explanation or documentation in the changelog or whareve, instead of using the obvious. Optimizing the version scheme to avoid a single character, at the cost of making this non-uniform and unobvious seems like the wrong thing to be optimizing on.