Preparations to switch to APK package manager

[aparcar]

Hi all, some fellow developers and me worked for some time now on making APK the new package manager for OpenWrt, replacing the unmaintained OPKG fork we've been using for the longest time.

APK is actively developed and used in multiple other distributions, e.g. Alpine Linux 🎉

While there is till some work ahead, I'd like to prepare everyone who maintains a package to verify that the PKG_VERSION follows Semantic Versioning <major>.<minor>.<fixup>[.<sub1>...]. APK uses a deterministic algorithm to compare versions and does not like random strings, except a valid hash prefixed with a ~.

If in doubt, please use the Docker container below to verify the used version is valid:

docker run --rm -it ghcr.io/aparcar/apk-valid-version <VERSION> [<VERSION> ...]

It will print whatever version is not valid, if you get a zero exit code, you're fine.

Please feel free to reach out for assistance and have a look at the core migration of versions.

[aparcar]

Below packages that would cause trouble. Please bear in mind that PKG_RELEASE is soonish prefixed with an r and may only contain a number.

Naughty list:

• luci-app-adblock-fast 1.1.1-5
• luci-app-advanced-reboot 1.0.1-9
• luci-app-https-dns-proxy 2023-11-19-1
• luci-app-pbr 1.1.1-7
• luci-proto-nebula 1.6.1-1

[stangri]

@aparcar I can pre-emptively add r to the revisions, I just wanted to confirm that it will not break opkg upgrade logic. For example, would opkg consider 1.1.1-r6 higher version than 1.1.1-5? Same question for 2023.11.19-r2 and 2023-11-19-1.

[hnyman]

would opkg consider 1.1.1-r6 higher version than 1.1.1-5? Same question for 2023.11.19-r2 and 2023-11-19-1.

Easiest is to bump the main version to 1.1.2 at the same time

(not sure about the date comparison with a changed separator)

[systemcrash]

@aparcar I can pre-emptively add r to the revisions, I just wanted to confirm that it will not break opkg upgrade logic. For example, would opkg consider 1.1.1-r6 higher version than 1.1.1-5? Same question for 2023.11.19-r2 and 2023-11-19-1.

Does opkg even do that? I'm under the impression that it does not compare versions.

See parse_version and compare

You could do away with 1.1.1-r6 altogether and just let git handle semantic versioning (at least for the time being), or use dates instead. For devs, the tip of the master branch is latest, for users, if it is updated, it will show as update available.

[systemcrash]

@feckert: date format here makes most sense. We won't be updating lua apps (this app is lua) any more so this change should be OK. Alt: update at source? https://github.com/lisaac/luci-app-dockerman

• luci-app-dockerman v0.5.13-20240317

[stangri]

docker run --rm -it docker.io/aparcar/apk-version-check [ ...]

BTW:

sudo docker run --rm -it docker.io/aparcar/apk-version-check 1.1.1-5
Unable to find image 'aparcar/apk-version-check:latest' locally
latest: Pulling from aparcar/apk-version-check
bca4290a9639: Pull complete
1ae19ff60baf: Pull complete
75e05e2c02ea: Pull complete
28c83907721f: Pull complete
Digest: sha256:e113fde83c649c3dc7cfed9b7e6c2068b94aad61f950cf9f0bfd93d9bcf69c86
Status: Downloaded newer image for aparcar/apk-version-check:latest
WARNING: The requested image's platform (linux/arm64/v8) does not match the detected host platform (linux/amd64/v2) and no specific platform was requested
exec /usr/bin/apk: exec format error

[aparcar]

@stangri I added a multi arch container here ghcr.io/aparcar/apk-valid-version

[jow-]

For example, would opkg consider 1.1.1-r6 higher version than 1.1.1-5? Same question for 2023.11.19-r2 and 2023-11-19-1.

root@OpenWrt:~# opkg compare-versions 1.1.1-r6 '>' 1.1.1-5 && echo true || echo false
true
root@OpenWrt:~# opkg compare-versions 2023.11.19-r2 '>' 2023-11-19-1 && echo true || echo false
true
root@OpenWrt:~# opkg compare-versions 1 '>' r1 && echo true || echo false
false
root@OpenWrt:~# opkg compare-versions r1 '>' 1 && echo true || echo false
true
root@OpenWrt:~# 

[stangri]

Thank you @aparcar @hnyman @jow-!

PRs with fixes:

• luci-app-adblock-fast: luci-app-adblock-fast: prepare migration to APK #7009
• luci-app-advanced-reboot: luci-app-advanced-reboot: prepare migration to APK #7010
• luci-app-https-dns-proxy: luci-app-https-dns-proxy: prepare migration to APK #7013
• luci-app-pbr: luci-app-pbr: prepare migration to APK #7011
• luci-proto-nebula: luci-proto-nebula: prepare migration to APK #7012

[systemcrash]

@feckert - how is dockerman update coming along?

[olumolu]

Status of dockerman will this be ready on 24.x

[krant]

@stangri latest luci-app-advanced-reboot fails to build with CONFIG_USE_APK=y

luci-app-advanced-reboot-1.0.1-11-1.apk: package version is invalid

[hnyman]

@aparcar
I started looking into trying to convert luci-app-opkg to a crude initial luci-app-apk, but stumbled rather quickly into trouble. The apk package info is formatted so differently than opkg, that the LuCI app requires major javascript work to even get it to read the available packages list and install new packages.

One challenge will be that our apk seems to produce rather small amount of information for available packages with "apk list -a" (and for installed ones with "apk list -I")

In style of

root@router6000:~# apk list -a
adblock-4.2.2-r3 all {feeds/packages/net/adblock} (GPL-3.0-or-later) [installed]
apk-openssl-3.0.0_pre20240806-r1 aarch64_cortex-a53 {feeds/base/system/apk} (GPL-2.0-only) [installed]
arptables-nft-1.8.8-r2 aarch64_cortex-a53 {feeds/base/network/utils/iptables} (GPL-2.0)
...
wifi-scripts-1.0-r1 all {feeds/base/network/config/wifi-scripts} (GPL-2.0) [installed]
wireguard-tools-1.0.20210914-r3 aarch64_cortex-a53 {feeds/base/network/utils/wireguard-tools} (GPL-2.0) [installed]
wireless-regdb-2024.07.04-r1 all {feeds/base/firmware/wireless-regdb} (ISC) [installed]
wpad-openssl-2024.03.09~695277a5-r3 aarch64_cortex-a53 {feeds/base/network/services/hostapd} (BSD-3-Clause) [installed]
xdp-filter-1.4.2-r1 aarch64_cortex-a53 {feeds/base/network/utils/xdp-tools} (GPL-2.0-only)
xdp-loader-1.4.2-r1 aarch64_cortex-a53 {feeds/base/network/utils/xdp-tools} (GPL-2.0-only)

Trouble starts already with package name and version being shown in combined form. I have not yet figured a way to have those listed separately by apk list. We might need to assume some regexp like ^([\w-]+)-(\d[\w\.\-~]*) (.[\w\-]*) (.*) (\(.*\))( \[installed\])*$ to parse the attributes from the single line into fields. Big change compared to opkg where each field was on its own row with a label.

Ps. Is there any support for OpenWrt specific definitions like essential, hold, etc.? "apk info -a" for an individual package shows more details, but so far I have not seen any OpenWrt specific attributes.

[dannil]

I haven't seen any news about it but do we know if 24.x will default to using APK? In that case we still need to fix luci-app-dockerman's version string, it's quite a popular app as well, shows up time to time on the forum.

[olumolu]

I haven't seen any news about it but do we know if 24.x will default to using APK? In that case we still need to fix luci-app-dockerman's version string, it's quite a popular app as well, shows up time to time on the form.

This seems to be unmaintained for more than a year.

[PalebloodSky]

I haven't seen any news about it but do we know if 24.x will default to using APK? In that case we still need to fix luci-app-dockerman's version string, it's quite a popular app as well, shows up time to time on the forum.

Thanks @hnyman for this fix 174e861 as I do use that package.

@dannil in regards to a larger effort, #7313 perhaps it stalled out.

[stangri]

Maybe there's a different reason, but I'm guessing apk sets the $PKG_UPGRADE to 1 and/or the entire uci-defaults script fails.

@AzimsTech if you can verify that the theme apk binaries contain the uci-defaults scripts that would be a good start.

[AzimsTech]

@stangri I get it now. I just need to reboot for the configuration to apply. I was not aware on how it works at first. I'm sorry for the false alarm. 🙏