Invalid RPM version strings when version contains multiple '-'

[nickajacks1]

What happened?

nfpm can produce RPMs with an invalid verison field. This happens when the version contains multiple hyphens, e.g. 1.2.3-alpha-beta-gamma. nfpm will identify alpha-beta-gamma as the prerelease and correctly join it with the version using a tilde, producing 1.2.3~alpha-beta-gamma. However, this version is invalid because hyphens are not allowed in version strings according to the official RPM documentation.

RPM almost handles the version correctly, but since hyphens are used as delimiters for parsing a NEVRA, you hit odd behavior at times:

$ rpm --dbpath=/tmp/asdf -q ABC --queryformat '%{VERSION}\n'
1.2.3~alpha-beta-gamma
$ rpm --dbpath=/tmp/asdf -q ABC
ABC-1.2.3~alpha-beta-gamma-1.x86_64
$ rpm --dbpath=/tmp/asdf -q ABC-1.2.3~alpha-beta-gamma
package ABC-1.2.3~alpha-beta-gamma is not installed

I think nfpm should either

• Transform the pre-release by replacing all hyphens with some other character such as _, ., or +.
• Warn the user in some way, but not try to modify the pre-release. Some ideas:
  • Print a warning if the parsed pre-release contains invalid characters
  • Error out if the parsed pre-release contains invalid characters
  • Put a note in the documentation somewhere about this pitfall

How can we reproduce this?

nfpm.yaml

name: ABC
version: 1.2.4-alpha-beta-gamma

nfpm p -p rpm

nfpm version

Latest main (41b3349)

       _____ ____  __  __
 _ __ |  ___|  _ \|  \/  |
| '_ \| |_  | |_) | |\/| |
| | | |  _| |  __/| |  | |
|_| |_|_|   |_|   |_|  |_|
nfpm: a simple and 0-dependencies apk, arch linux, deb, ipk, and rpm packager written in Go
https://nfpm.goreleaser.com

GitVersion:    dev
GitCommit:     unknown
GitTreeState:  unknown
BuildDate:     unknown
BuiltBy:       unknown
GoVersion:     go1.22.3
Compiler:      gc
ModuleSum:     h1:RUmeEt8OlEVeSzKRrO5Vl5qVWCtUwx4j9uivGuRo5fw=
Platform:      linux/amd64

Search

• I did search for other open and closed issues before opening this.

Code of Conduct

• I agree to follow this project's Code of Conduct

Additional context

No response

[caarlos0]

see #836