Cfrgtkky

I have a Launchpad recipe that looks like this:

# git-build-recipe format 0.4 deb-version {latest-tag}-0~{time}~rev{revno}~pkg{revno:packaging}

lp:kvantum master

nest packaging lp:~krisives/kvantum/+git/kvantum-packaging debian master

However, the upstream prefixes the version numbers with a V which causes the packaging process to complain that versions must begin with a number. The author wants to keep his V prefixed tag names.

Other than manually modifying the changelog in my packaging repository is there a way to have the recipe automatically use the {latest-tag} without breaking the build process?

One workaround is to simply make sure that the upstream version part of your package version does start with a digit by inserting one. For example, you could use:

# git-build-recipe format 0.4 deb-version 0{latest-tag}-0~{time}~rev{revno}~pkg{revno:packaging}

Note that this will compare lower than anything you might have already published with your current expansion, however, since for example 0V1 sorts after V1. If you must, you could use an epoch (eg. 1:0{latest-tag}-0~{time}~rev{revno}~pkg{revno:packaging} to ensure it sorts higher than anything published previously, but this bump is not reversible and so should be avoided if at all possible.

For further information:

• You can find an explanation of how packaging version strings work in
  section 5.6.1.2 of Debian
  policy.




• You can find the exact implementation of the variable expansions by starting with
  the source of the git-build-recipe
  package.




• See the documentation of how recipes
  work,
  including details on the variable
  expansions.
  Note though that this documentation is really for bzr-based recipes,
  and the implementation for git is merely documented as "similar"
  (there's a bug open on
  this).




• You can test package version string comparisons with dpkg --compare-versions, for example dpkg --compare-versions 0V1 gt V1 && echo true || echo false. See dpkg(1) for details.

I don't see any option in the documentation to do anything with the "latest upstream tag" apart from to embed it in your final version string, nor any other way to grab the upstream version if the tag is the only place upstream declare it. Therefore I think my workaround, or something like it, is your only option at the moment, but we can see if anyone else has any other answers.

If the workaround is not acceptable to you, bug reports against git-build-recipe are welcome including for feature requests to cover new use cases such as this. I can't speak for what the answer will be as to what enhancements would be suitable in general, though. An enhancement to provide a regexp-based substitution inside an expansion might be possible, for example, but would probably need to be implemented in a way that ensures that malicious code cannot be executed on the host running git-build-recipe in the face of an untrusted recipe input. It would probably be best to find agreement in a bug first, before attempting to implement such a feature enhancement.