package-url
Contradicting namespace case requirement for apk
The apk purl type contains the text:
The namespace is the vendor such as alpine or openwrt. It is not case sensitive and must be lowercased.
Is the namespace not case sensitive or should it be lowercased? The two requirements contradict each other.
cc @Foxboron who initially authored the PR
The wording is copied from the rpm definition and several other definitions has the same wording.
I just read it as "should be normalized".
https://github.com/package-url/purl-spec/blob/master/PURL-TYPES.rst#rpm
It's confusing even if it's worded that way elsewhere IMO. @stevespringett thoughts?
If it's accurate to say "It must be lowercased", why not just say that? I might be missing something, but atm it's not clear what It is not case sensitive and adds to the rule/spec other than the possibility of confusion.
That phrasing is used many times, as well as the occasional It is case insensitive and must be lowercased . . . . as with the huggingface type.
I like the wording:
The name is case-insensitive and therefore should be normalized to lowercase.
Like it is written in rfc3986. The must makes no sense here for me because it's case-insensitive.
apk was originally for openwrt only. Mixing it in with alpine is a mistake that should not have been merged as the apk from alpine and the apk from openwrt are completely different animals, last I looked?. We need to recover somehow
@pombredanne That is confusing. apk was not originally for openwrt, neither in implementation nor in the spec notes here. What is the mixing issue you are refering to?
Stumbling on this, note that "apk" is also the name for Google's Android packages.
- either OSS from a stock AOSP / Android Open Source Projects,
- or "aftermarket" OSS distributed on Google Play application store,
- or closed source distributed by Google Play or third part application stores.
From official Android documentation: https://source.android.com/s/results?q=apk&text=apk
The Alpine Package Format predates android by.. a decade? Google choosing a conflicting name is unfortunate.
@jbmaillet the ship has sailed on apk as a package type based on @Foxboron contribution. For better or worse, I had planned early on for using alpine as a type for Alpine .apks https://github.com/Foxboron/purl-spec/blame/1b1e9b2afa6de1c855225fb08cb46878ad653925/PURL-TYPES.rst#L241 .... but @Foxboron PR was merged and is fine... in hindsight with other alpine-based distro like wolfi, this make sense.
@jbmaillet OpenWRT is not using (much yet) the alpine format, nor is android. Here is my understanding of .apk land:
- alpine's apk is multiple gzips in a tarball with a .PKGINFO metadata file, basically inherited from arch. For instance at https://dl-cdn.alpinelinux.org/alpine/v3.22/main/x86/ ... spec at https://wiki.alpinelinux.org/wiki/Apk_spec ...
- but that's the apk v2 format https://gitlab.alpinelinux.org/alpine/apk-tools/-/blob/master/doc/apk-v2.5.scd that you can process with tar and gzip
- There is also a (new) v3 format that is a completely different custom binary https://gitlab.alpinelinux.org/alpine/apk-tools/-/blob/master/doc/apk-v3.5.scd and that I do not see yet in much use. This cannot be processed by standard tools. Comes with its own magic https://gitlab.alpinelinux.org/alpine/apk-tools/-/blob/636592155a7f39e427cec53e172cdfecacba711b/src/adb.h#L47 ... and I cannot fathom extracting it using standard tools. It needs apk. @fabled please confirm :) (this is a small PITA as this means it cannot be extracted everywhere)
- android's apk is a zip with extra conventions. We need to add that as a type IMHO.As mentioned here ... it came after Alpine.
- openwrt should be its own type as it is a bit more complex:
- they use opkg with a .ipk file format which overall is similar to Debian's https://archive.openwrt.org/releases/24.10.1/targets/x86/64/packages/
- and are transitioning to use alpine's apk as a tool, using the v3 apk format
~~@pombredanne openwrt is planning on deprecating opkg in favour of apk. Thus we do not need to consider the openwrt package format in the future.~~
I see this point has already been made 🫠