Spec file versioning macros

[LecrisUT]

This is a reference from fedora packaging committee issue:

I would like to propose a few helper macros for dealing with version control:

• Format git tag -> rpm version: e.g. 1.2.3-rc1/1.2.3rc -> 1.2.3~rc1. This could be detected from python's packaging.version
• Format rpm version -> git tag/free format: e.g. 1.2.3~rc1 -> 1.2.3-rc1. An interface for this could be: %{version_format -base 1.2.3 -prerel rc1 -format v{base}-{prerel}} or if possible more automated %{version_format -version %{version} -format v{base}-{prerel}}
• Detect version from git tag/.git_archival.txt similar to setuptools_scm. This would be incredibly useful for in-source packaging, but not in dist-gits

These issues arose when trying to make packit be able to parse the version from git tags like v1.2.3-rc1. We can make a custom handling there, but it would be better to have a more standardized way to do this. The best case is to implement these upstream so that these can be used by OpenSuse as well.

For reference here are a few workarounds that have to be maintained and are inconsistent with each other: bluefish, cmake

Ideally it should be implemented here, but should it first be developed on redhat rpm macros?

Related issues:
packaging committee, redhat-rpm-config issue, #1219

[jengelh]

Just a comment, the mapping between git tag and rpm is one way. You can't tell if the rpm-ized string 1.2.alpha came from a git tag string 1.2~alpha, 1.2-alpha or 1.2.alpha.

[LecrisUT]

But when we use the formatting macro, we have the original git tag info, so we can reuse it later. For the reverse, if we can extract the macro info, e.g. from %{version} we could have %{version_base} and %{version_prerel} and we can construct the git tag accordingly e.g. v%{version_base}%{?version_prerel:-%{version_prerel}. This one I don't know how useful it would be, but the first one I think it is very beneficial.

[ffesti]

May be Fedora should figure out how to make this work first. We can merge an existing macro much easier than figuring this out ourselves without knowing all the use cases.