APK: setting release creates invalid package version

[devfbe]

What happened?

I'm currently trying to package APK packages beside DEB and RPM packages. In my example I use the following configuration (explicitly set all versions)

name: testpackage
arch: "amd64"
platform: "linux"
version: 1.4.4
release: 1289492819
maintainer: "Test Maintainer <test@example.org>"
description: |
  My Test tool
contents:
- src: ./testbinary
  dst: /usr/bin/testbinary

When packaging this as deb, rpm and apk, the following package metadata will be created:

############################################################
# RPM good (valid)
############################################################
Epoch       : 0
Version     : 1.4.4
Release     : 1289492819
############################################################
# DEB good (valid)
############################################################
Version: 1.4.4-1289492819
############################################################
# APK not good (invalid)
# Expected -r1289492819 or _p1289492819, but not -1289492819 after the version
# (where Something is a timestamp)
############################################################
pkgver = 1.4.4-1289492819

The created pkgver is invalid which can be checked using apk version --check (empty response means everything is okay):

❯ podman run -ti --rm alpine:latest
/ # apk version --check 1.4.4-1289492819
1.4.4-1289492819
/ # apk version --check 1.4.4_p1289492819
/ # apk version --check 1.4.4-r1289492819
/ #

Expectation: nfpm generated a package with -r<release> or _p<release> - assume that -r<release> is the best way here.

Additionally, the resulting file name should not contain an architecture but only the version string (e.g. dhcp-doc-4.4.3_p1-r4.apk (name of the package, _p if there is some kind of patch(?) version and then -r if there is a package version specified)

How can we reproduce this?

Build an apk package with the described configuration above, then:

  mkdir /tmp/extracted
  cp *.apk /tmp/extracted
  cd /tmp/extracted
  for i in *.apk; do mv $i "${i}.gz"; gunzip "${i}.gz"; tar -xf "${i}"; done
  cat .PKGINFO

nfpm version

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

GitVersion:    2.35.3
GitCommit:     5ace4da2fd3162383a16218e2ef405dc2676bdfc
GitTreeState:  false
BuildDate:     2024-01-31T17:53:18Z
BuiltBy:       goreleaser
GoVersion:     go1.21.6
Compiler:      gc
ModuleSum:     h1:YGEygriY8hbsNdCBUif6RLb5xPISDHc+d22rRGXV4Zk=
Platform:      linux/amd64
{code}

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

Source code of the apk tools (version.c)

[devfbe]

I finally found a documentation describing the package naming format:

https://wiki.alpinelinux.org/wiki/Package_policies

Relevant part:

Package versions are similar to gentoo or other distributions, e.g. 10.2.33, 4.5_alpha, 20200712-r0:

• See Semantic Versioning
• Alpha, release candidates (_rc2), etc are prefixed with underscore _ not a hyphen.
• Subsequent package versions are -r0, -r1, and so on; the number is from $pkgver.
• Subsequent package fixes are _p0, _p1.
• Test your proposed version with apk, for example apk version --check 3.2.1-rcN. The result is nothing if it is valid.

[devfbe]

I inspected the linked version source code and figured out what the statements above mean (and I took a look at some alpine APKBUILD files to verify that:

An APK "full" version consists of

<package-version>_<prerelease-version>_<postsuffix>-<package-release-version>

The prerelease may start with
static const char *pre_suffixes[] = { "alpha", "beta", "pre", "rc" }; followed by digits.

The "post release / subsequent package fixes" version can start with:
static const char *post_suffixes[] = { "cvs", "svn", "git", "hg", "p" }; followed by digits.

The name "subsequent package fixes" seems to be misleading because a look at the alpine repository indicates, that the post_suffixes are mostly for adding additional values that are needed to lookup the upstream artifact when building.

I would assume that the following configuration should lead to the following outcome:

version: 1.2.3a_p15
release: 47

1.2.3a_p15-r47

version: 1.2.3a
prerelease:  alpha1
release: 47

1.2.3a_alpha1-r47

Would you agree with that? If yes, I would create a merge request for that change.

[caarlos0]

If I understood correctly, #794 should fix it

[caarlos0]

thanks for the report, btw 🙏🩵

[devfbe]

Wow, awesome, thanks for fixing that so quickly!