Open joemiller opened 9 months ago
After doing some more testing on this it is not as simple as multiple _
in a version string.
The _
is recognized as the start of TOKEN_SUFFIX separator: https://gitlab.alpinelinux.org/alpine/apk-tools/-/blob/2.14-stable/src/version.c?ref_type=heads#L46-47
And the expectation for what is allowed next is here: https://gitlab.alpinelinux.org/alpine/apk-tools/-/blob/2.14-stable/src/version.c?ref_type=heads#L105-124
git
is listed as one of the recognized post_suffixes
: https://gitlab.alpinelinux.org/alpine/apk-tools/-/blob/2.14-stable/src/version.c?ref_type=heads#L74
But in my testing it appears that only strings with numerics following git
are allowed:
(TIL: apk version
sub command can be used to exercise the version validation and comparison logic):
$ apk version -c 8.0.34.20231212_git1123456789-r0 ; echo $?
0
$ apk version -c 8.0.34.20231212_gitb2345a6789-r0 ; echo $?
1
I don't see any test cases for the git
post-suffix so it would not surprise me if this is a bug, as I don't see how the git suffix would be useful with strings only containing numerics. Test cases: https://gitlab.alpinelinux.org/alpine/apk-tools/-/blob/2.14-stable/test/version.data?ref_type=heads
TL;DR - alpine uses Gentoo's versioning scheme (https://gitlab.alpinelinux.org/alpine/apk-tools/-/blob/2.14-stable/src/version.c?ref_type=heads#L15) which is a bit limited compared to opkg/debian/pkgconfig's algorithm, and there may be work to change this in the future, possibly a v3.x release of apk-tools
: https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10830
I came across a slightly obscure bug, or at least I think it's a bug. I was building a package with
melange
that contained a version string with dashes and I noticed that alpine'sapk
would fail withpackage file format error
on a specific case: A sub package with aprovides =
line containing an invalid version string.apk
seemed happy to install packages with invalid versions in them but fail on packages with invalid versions in the.PKGINFO
header file. In my case I found this happen on aprovides = cmd:foo-$BAD_VERSION
line, but it could happen ondepends =
lines too.In our case the version string we were using was roughly:
8.0.0.20231201-ps-f1234567
Here is a reproducible example. I'll use the
zlib.yaml
from the melange/os repo. It doesn't matter the package, I just needed something quick to compile for the reproduction example.I have made two changes to zlib.yaml from the original melange version:
version
modified to add-f12345678
. Adding anything containing a dash is the key here.dev
subpackage to add a "binary"/usr/bin/foo
, since the issue does not seem to appear untilapk
attempts to parse theprovides = cmd:foo[VERSION]
line of thedev
package's.PKGINFO
file.Modify the
zlib.yaml
and setversion: 1.3
and thedev
package will work fine.I am not sure if this bug should be in this repo or the melange repo, nor what the exact fix should be, other than to match the version validation logic from https://gitlab.alpinelinux.org/alpine/apk-tools/-/blob/2.14-stable/src/version.c
EDIT: After further testing it appears that only a single
_
is allowed in the version string. The same version validation failure will occur on a version string likeversion: 1.3_f12345678_foo