Impossible to get upstream source if tag is not <version> or v<version>

[nodens]

Hi,

While giving a try on github.com/lxc/lxd, wanting to package the new 4.0.0 version, I stumbled upon the following issue:

2020/04/04 17:08:52 Starting "dh-make-golang v0.3.3 linux/amd64"
2020/04/04 17:08:52 Downloading "github.com/lxc/lxd/..."
2020/04/04 17:09:05 Determining upstream version number
2020/04/04 17:09:05 Found latest tag "lxd-4.0.0"
2020/04/04 17:09:05 WARNING: Latest tag "lxd-4.0.0" is not a valid SemVer version
2020/04/04 17:09:05 Latest tag "lxd-4.0.0" matches master
2020/04/04 17:09:05 Package version is "lxd-4.0.0"
2020/04/04 17:09:06 Determining dependencies
2020/04/04 17:09:17 Downloading https://github.com/lxc/lxd/archive/vlxd-4.0.0.tar.gz
2020/04/04 17:09:17 Could not create a tarball of the upstream source: 404 Not Found

indeed, the upstream tag being lxd-, dh-make-golang fails at getting the version right.

A way to solve this could be

• allow the user to provide the version (and the tag to search) (most versatile)
• allow the user to specify a string to remove from the tag instead of v (probably easiest)

This is, in a way, related to issue #31 and PR #34

Cheers,

[creekorful]

Hello @nodens,

I have stumbled upon the same issue while trying to package a library that was named wrongly:

The upstream maintainer has released a tag named "v" for the latest version, and after realizing his mistake, has created another v1.x.x version.

Despite of that, dh-make-golang try to use the version named v (provided by the git describe --abbrev=0 --tags --exclude /v command) and always fails because later on, dh-make-golang remove the 'v' prefix, ending then with an empty string as package version.

I think the proper way would be to add a version flag parameter to the make command, to be able to retrieve the specific upstream version. Version flag will be the name of the git tag to use.

I know that there is a git_revision parameter, but it's not working in my case, because the revision will correspond to the both two tags

This will solve our issue, as well as provide the ability for a maintainer to package a specific version of upstream, not necessarily latest.

What do you think about it?

[nodens]

I think the proper way would be to add a version flag parameter to the make command, to be able to > retrieve the specific upstream version. Version flag will be the name of the git tag to use.

I think it's nice to be able to specify the exact tag we want. But then, we might end up with the wrong version string, e.g. in my case lxd-4.0.0 is not a proper version. I agree it's nothing that can't be fixed afterwards in editing the changelog, though. So it provides a workaround for this issue, but not an actual fix IMO.

That said, again, it'd be nice to be able to specify the exact tag, it's just that I'm not sure it's a complete fix for this issue.

[creekorful]

Hello back @nodens, I've just stumbled across the same issue for another package.

That said, again, it'd be nice to be able to specify the exact tag, it's just that I'm not sure it's a complete fix for this issue.

You are totally right, it does not cover the case wrong named tag at all. I can provide another fix for that once my original PR is merged.

One of your proposal:

allow the user to specify a string to remove from the tag instead of v

Seems the best idea for me. Once the 2 PR got merged we will cover these two scenarios:

• Being able to package the tag (not refspec) that we want. So we will cover the case of two tags pointing to the same refspec.
• Being able to remove a prefix from a version, so that we can package even if the tag are not properly named.

What do you think about this?

[nodens]

Hi,

sorry I took so long to reply - I was away from Go packaging for a while.

Actually I'm not sure what the best would be. Having a way to force a specific tag and specify the version seems to be what we need here.

FTR, since I still have the issue with lxd (now tagged lxd-4.0.4), I just end up using
- git_revision=lxd-4.0.4 -force-prerelease and fix the changelog. -force-prerelease is needed, otherwise dh-make-golang uses the tag (minus leading v) as version, so lxd-4.04 in this case, and wants to get the tarball at .../v<tag> which will give a 404.

IMO dh-make-golang should be a bit more flexible, and allow user to provide tag, version, and tarball url if needed.

Cheers!

[anthonyfok]

A bit of clarification is needed:

With commit 581a5e8, dh-make-golang v0.4.0 and up can now fetch github.com/lxc/lxd correctly:

$ dh-make-golang github.com/lxc/lxd
2021/08/30 06:05:34 Starting "dh-make-golang v0.5.0 linux/amd64"
2021/08/30 06:05:34 Downloading "github.com/lxc/lxd/..."
2021/08/30 06:05:50 Determining upstream version number
2021/08/30 06:05:50 Found latest tag "lxd-4.17"
2021/08/30 06:05:50 WARNING: Latest tag "lxd-4.17" is not a valid SemVer version
2021/08/30 06:05:50 INFO: master is ahead of "lxd-4.17" by 234 commits
2021/08/30 06:05:50 Package version is "4.17"
2021/08/30 06:05:50 Determining dependencies
2021/08/30 06:06:11 Downloading https://github.com/lxc/lxd/archive/lxd-4.17.tar.gz
2021/08/30 06:06:16 Assuming you are packaging a program (because "github.com/lxc/lxd/fuidshift" defines a main package), use -type to override
2021/08/30 06:06:16 Moving tempfile to "lxd_4.17.orig.tar.gz"
...

But I like the idea proposed in PR #140 Allow to make package from specific upstream tag too, as some Go repos use multiple release tag prefixes for the different modules or subpackages that they contain. Probably -git_revision can handle it? (or not?)
Perhaps we can revisit this at a future date.

(I was feeling guilty that my commit 581a5e8 in November 2020 seems to have overriden #140, but on a closer look, #140 was closed without merging in October 2020, and the code of the PR is no longer accessible, and it was before I started working on commit 581a5e8, so all is good! No need to feel guilty! Haha!)