close
Skip to content

fix: append +ds1 suffix to upstream version when repacking#298

Open
aviralgarg05 wants to merge 2 commits intoDebian:masterfrom
aviralgarg05:fix-issue-141-version-alignment
Open

fix: append +ds1 suffix to upstream version when repacking#298
aviralgarg05 wants to merge 2 commits intoDebian:masterfrom
aviralgarg05:fix-issue-141-version-alignment

Conversation

@aviralgarg05
Copy link
Copy Markdown

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
Copy link
Copy Markdown
Contributor

ottok commented Jan 19, 2026

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
Copy link
Copy Markdown

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
Copy link
Copy Markdown
Author

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

@aviralgarg05 aviralgarg05 force-pushed the fix-issue-141-version-alignment branch from 8915e54 to 42840db Compare January 19, 2026 10:32
@ottok
Copy link
Copy Markdown
Contributor

ottok commented Jan 19, 2026

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
Copy link
Copy Markdown
Author

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
Copy link
Copy Markdown
Contributor

n-peugnet commented Jan 20, 2026

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
Copy link
Copy Markdown

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
Copy link
Copy Markdown
Author

Reverted back to the correct one!

@ottok
Copy link
Copy Markdown
Contributor

ottok commented Jan 20, 2026

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
Copy link
Copy Markdown
Contributor

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
Copy link
Copy Markdown
Contributor

ottok commented Feb 28, 2026

@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
Copy link
Copy Markdown
Contributor

ottok commented Apr 6, 2026

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?

When vendorDirs or Godeps are detected, append the +ds suffix to the
upstream version. This ensures consistency between the generated
debian/changelog, debian/watch, and orig tarball naming.

The +ds suffix (without digit) follows the Lintian anticipated-repack-count
recommendation and aligns with uscan defaults.

Fixes: Debian#141
@aviralgarg05 aviralgarg05 force-pushed the fix-issue-141-version-alignment branch from 1093917 to 58fbe05 Compare April 6, 2026 19:31
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

upstream tag/version is not aligned with uscan file

4 participants