The version format for virtual packages (YYYYmmdd.HHMMSS) doesn't include a pkgrel like packages normally have (<pkgver>-r<pkgrel>).
This creates ambiguity in the output of the apk list command. Normally it is enough the strip the last 2 dashes but that doesn't work with the version format of virtual packages:
<pkgname>-<pkgver>-r<pkgrel>
<pkgname>-YYYYmmdd.HHMMSS
I suggest adding -r0 to the version of virtual packages app_add.c#L118. !132 (closed) does fix the apk list problem too but a consistent version format would still be better.
Edited
Designs
Child items
...
Show closed items
Linked items
0
Link issues together to show that they're related.
Learn more.
The -r0 suffix is Alpine specific. APK (and potentially other apk using distributions) do not use it. It is a long standing known inconvenience that the pkg-ver is not always easily parsed to pkg and ver.
@ncopa Did we ever come with a good plan how to disambiguate this?
Or we could use a space as separator instead for the apk list.
Originally it was possible separate version by looking for the last dash with a following digit, -[0-9] (or something similar). This was inherited from Gentoo version scheme.
Or we could use a space as separator instead for the apk list.
Should be fine too.
Originally it was possible separate version by looking for the last dash with a following digit, -[0-9] (or something similar). This was inherited from Gentoo version scheme.
Might have worked for Gentoo but this doesn't work with current used package names. eg webkit2gtk-6.0-2.42.4-r0
My opinion here is that we should change that to webkit2gtk6.0-2.42.4-r0, update documentation to mention this, and add a test for this in pkgname validation.
I suppose it is my bad that this was not clearly documented before.
This is actually fairly unfortunate, the example above would produce identical .apk filenames and result in broken repository.
Should we establish some sort of pkgname rules that both abuild and apk mkpkg would start to enforce that guarantee this is not possible, and allow non-ambiguous splitting of the filename to pkgname and pkgver?
First step is prohibiting number after a dash in pkgname. But should we then also enforcepkgver` to start with number?
First step is prohibiting number after a dash in pkgname.
That would require many (73) package renames, check apk list '*-[0-9]*'! I think that font-bitstream-100dpi is the most readable name for that package.
Parsing would be easier if characters were disallowed completely instead of specific combinations.
These could currently create problems in specific edge case: \n, \r, @, \x00, ~, =, /, <, >, maybe spaces too?
I suggest disallow all/most of them and use one of them for the file name and apk-list.
$ apk list "*-[0-9]*" | sed -e 's/.*{\(.*\)}.*/\1/g' | sort -u
That would be 42 source packages affected.
@ncopa should file abuild and aports bugs to fix those so that the old rule applies. Or should we consider changing apk package naming change and output changes to make things work.
I generally don't see how any ambiguity exists in the first place. The version in general cannot contain dashes; the package version generally cannot contain a dash, the one exception and special case being the revision number (-rN). This is handled specially in the version parser, see https://gitlab.alpinelinux.org/alpine/apk-tools/-/blob/master/src/version.c?ref_type=heads#L49
That means you can unambiguously split the names using the following approach:
If the string ends with -rN suffix, consider it a part of the version; if not, ignore
Search for the next last dash in the string
Split by that dash; left part is pkgname, right part is version
The package-git-0.2 cannot be ambiguous - here the name is alwayspackage-git and the version is 0.2. The other case cannot be, as git-0.2 does not parse as a valid pkgver.
You might be able to raise nonsense stuff like empty pkgver or pkgver that is just a suffix, but it sounds to me like that is just something that should be prevented in the version parser anyway if that parses; I don't think these should canonically be considered valid versions.
It's probably not a bad idea to switch the separator anyway to make parsing less clunky, but I don't think the current format technically has any ambiguity.
It's probably not a bad idea to switch the separator anyway to make parsing less clunky, but I don't think the current format technically has any ambiguity.
It might be possible to parse everything correctly but it requires a lot of (undocumented) knowledge about the version format.
A = character seems like a good choice. I don't know how safe it is for file names and urls.
it sounds to me like that is just something that should be prevented in the version parser anyway if that parses; I don't think these should canonically be considered valid versions.
I agree that some of these things should be considered invalid.
it doesn't; the version format is literally just {digit}{.digit}...{letter}{_suf{#}}...{-r#} as is documented - as far as i know, everything else is invalid
Ok, I meant documented outside of the source code. The source code is normally not available as part of the documentation. But that can be fixed by adding the format to apk-version(8).
I think this is fairly fundamental to have some sort of consensus on what the pkgname and pkgversion can and should look like to satisfy the implicit requirements discussed in this issue.
We should also coordinate apk-tools, abuild, aports contents, and other things to agree on this. I think step one is to write a specification on this.
Another corner case is that the wiki mentions that pkgname should have lower case letters only, however:
$ apk search|grep [A-Z]|wc -l47
Once we have specification. We can update things as follows if bad name / version is encountered:
abuild can warns (later gives errors)
apkbuild-lint can give error
apk-tools mkpkg (v3) can give error
other tooling based on apk can decide on similar basis
Based on aports, I see use of A-Z, a-z, 0-9, and characters ._+-.
Is the initial proposal of:
pkgname shall consist of the following characters A-Za-z0-9._+-
In pkgname it is not allowed to have a number (0-9) after a dash -.
pkgver shall always start with a digit 0-9 and follows the construct of: {digit}{.digit}...{letter}{_suf{#}}...{-r#}
The following version suffixes are sorted in this order: alpha, beta, pre, rc, <no suffix>, cvs, svn, git, hg, p
The above rules guarantee that a $pkgname-$pkgver printed tuple can be split back to pkgname and pkgver from the first (and only) occurance of -[digit].
Do we want any other adjustments at this time? E.g. enforcing lower case characters only? Or e.g. potentially removing dot or underscore from allowed characters in pkgname?
Right. Perhaps we can also note that we might extend it to have the epoch prefix of {digit:} or similar.
Also, #10830 (closed) is about supporting alternative version schemes. Though, I am not sure how this could be done in a sane way. Would probably need to be build-time config option, but that would cause unexpected things if the repository used expects the other variant.
In pkgname it is not allowed to have a number (0-9) after a dash -.
This needs to be allowed. We have packages like:
font-adobe-100dpi
ntfs-3g
freeswitch-sounds-music-8000
libretro-3dengine
The version number is separated by the last-[0-9]. This means that the version string is not allowed to have any dash - followed by a number, -[0-9].
The above rules guarantee that a $pkgname-$pkgver printed tuple can be split back to pkgname and pkgver from the first (and only) occurance of -[digit].
No. I is separated by the last occurance of -[digit].
Right. Perhaps we can also note that we might extend it to have the epoch prefix of {digit:} or similar.
Please note that : is not allowed on FAT filesystems, and Alpine need to be able to store package file on FAT. Alpine will not be able to use the epoch at all if : (or any other character not allowed on FAT) is the separator.
Thanks for these. Let's write a formal specification based on the above and also give examples how to do the splitting (using shell) to clarify the mistakes. Once this is done we can start updating the tooling.
Do you know if ~hash works on fat? Can we add that as-is?
I think the standard is : as epoch separator. Though, it is also inconvenient because the if it is version or epoch cannot be determined without prefetching the separator. We could always translitterate it to some other character for the filename if needed.
@fabled I don't know if it was intentional but you dropped the digit+letter+digit version format. That causes problems with the alpine linux database which has versions using this format (#10987 (closed)).
I think 0.1a1 was never officially valid format. But it was silently accepted for index and package inputs. Apk did not enforce valid version until with recent commit. I wonder if we should still do the same for apkv2 index files.
from my testing apk deals fine with already indexed packages with invalid versions, and even generally handles version comparison correctly for this particular case