When looking at a different package manager, maybe the OpenWrt version upgrade process can also be made simpler in the future.
One of the biggest downsideds of OpenWrt in contrast to sth. like OPNsense ist that an upgrade every time brings manual work for the user to get his formerly installed packages back.
Do you know about LuCI Attended Sysupgrade, auc, owut and the Firmware Selector? All of those reconstruct your current package installation so that an upgrade requires no further work.
3 Likes
That question is orthogonal to the mechanics of the package manager, and more a result of the small flash sizes of the primary devices we're dealing with, their bootloader constraints and to some extent the manpower behind OpenWrt.
If you wanted in-place upgrades, you'd primarily need two things:
- at least 2 GB disk size, for all supported devices
- a flexible bootloader (e.g. UEFI+grub), that can deal with multiple kernels, change between them and load from removable media
only with this as lowest common denominator for all supported devices, you could look forward to a paradigm shift on the packaging side - but we already have that, in the general purpose desktop/ server distributions.
If you want to support devices with 8-16 MB flash, you have to make hard decisions - and the ancient/ lobotomized bootloaders provided by the OEM aren't making that any easier.
8 Likes
@aparcar
What is the intended flash usage strategy with apk?
I made an apk test build, and used your buildbot as the package repository.
I noticed that using apk to install one package caused apk to copy the whole database to flash. That increased the flash usage by 800k.
root@router6000:~# du /lib/apk
762 /lib/apk/db
212 /lib/apk/packages
974 /lib/apk
root@router6000:~# du /overlay/upper/lib/
4 /overlay/upper/lib/
root@router6000:~# apk update
fetch https://buildbot.aparcar.org/targets/mediatek/filogic/packages/packages.adb
[https://buildbot.aparcar.org/targets/mediatek/filogic/packages/packages.adb]
OK: 1397 distinct packages available
root@router6000:~# du /overlay/upper/lib/
4 /overlay/upper/lib/apk/db
7 /overlay/upper/lib/apk
11 /overlay/upper/lib/
root@router6000:~# apk add nand-utils
(1/1) Installing nand-utils (2.2.0-r1)
Executing nand-utils-2.2.0-r1.post-install
OK: 71 MiB in 300 packages
root@router6000:~# du /overlay/upper/lib/
768 /overlay/upper/lib/apk/db
4 /overlay/upper/lib/apk/packages
4 /overlay/upper/lib/apk/exec
779 /overlay/upper/lib/apk
782 /overlay/upper/lib/
root@router6000:~# ls -l /overlay/upper/lib/apk/db
-rw-r--r-- 1 root root 227550 Sep 1 11:57 installed
-rw------- 1 root root 0 Sep 1 11:57 lock
-rw-r--r-- 1 root root 551936 Sep 1 11:57 scripts.tar
-rw-r--r-- 1 root root 0 Sep 1 11:57 triggers
In comparison, using opkg to install one package, seems to cause much smaller disk space usage for /usr/lib/opkg
I wonder if apk usage will hurt small-flash routers, and will in practice lead to requiring somewhat larger flash in routers. (16 MB flash might be problematic, if user is not careful)
6 Likes
APK news tldr: As of now, the plan is for 24.10-rc to remain on opkg and have snapshot move to apk right after the 24 branch is made. If testing on snapshot is smooth, maybe merge it to 24 for the release.
@aparcar's full report: https://lists.openwrt.org/pipermail/openwrt-devel/2024-October/043348.html
10 Likes
After the latest fixes, also the renamed LuCI app luci-app-package-manager should work ok with APK.
(Buildbot has not yet built versions including today's fixes, but the package can be compiled from sources.)
4 Likes
For the apk itself, the patch from @ansuel for enabling "apk list full" is still needed for the LuCI to work ok, as commit https://github.com/openwrt/openwrt/pull/16767/commits/4e645db4a6c81f916f2d499fd9a79bc6bc9f0274 is not yet merged.
The public key for aparcar's test buildbot is also needed, available from https://github.com/openwrt/openwrt/pull/16767/commits/82f3a3bf79bfae2300f4540897459b95b842ac18
As aparcar's buildbot download site has pretty complete packages availability, testing is already well possible.
The test PR https://github.com/openwrt/openwrt/pull/16767/ contains those, as well sets the config options properly.
For my own builds I have just taken aparcar's key and that patch from ansuel, and set the options in my .config recipe by hand to have the apk-openssl (instead of mbedtls, as my whole build is openssl based)
##### APK instead of opkg
CONFIG_USE_APK=y
CONFIG_PACKAGE_apk-openssl=y
# CONFIG_PACKAGE_apk-mbedtls is not set
CONFIG_IMAGEOPT=y
CONFIG_VERSIONOPT=y
CONFIG_VERSION_REPO="https://buildbot.aparcar.org"
CONFIG_VERSION_CODE_FILENAMES=n
CONFIG_VERSION_FILENAMES=n
5 Likes
Tomorrow is the day. APK will become the default package manager on main snapshot as of 2024-10-11:
https://lists.openwrt.org/pipermail/openwrt-devel/2024-November/043378.html
Edit: In fact, just as I was typing the above, it hit. https://github.com/openwrt/openwrt/commit/40b8fbaa9754c86480eefc3692c9116a51a64718
11 Likes
Apk has been set as the default package manager a few hours ago, and buildbot has started to crunch images & later also packages.
When thinking at our two-stage buildbot, there are a few things to remember:
- first the phase1 main OpenWrt & images buildbot needs to build the core images and SDKs for each target. That is hopefully completed today.
- only after there are the needed SDKs in place, the phase2 packages buildbot can build packages according to the new apk scheme. That may take 2-3 days for some targets. (Until that it will use the existing old opkg based SDK)
So, there may be 1-3 day gap in the package availability in the worst case. That will also prevent imagebuilder, auc, owut, whatever... tool usage if pre-compiled .ipks are needed for the tool.
Also, there will not be opkg compatible package .ipks and package indices for the architectures that already have the new apk compiled packages. So, old already installed main/master snapshots will likely without be package installation possibitilies rather soon.
@aparcar has not yet posted any pinned news on forum, but I think that something might be good to have. He knows best the planned roll-out.
7 Likes
apk for alpine
opkg for openwrt
pkg for termux
1 Like
@hnyman can you point me to the code which creates the required manifests to set up the packages repo filled with APKs for OpenWrt? I publish the test versions of my packages in a repo, would like to look into an option of doing that for APKs.
Is there a way to export the list of packages installed by opkg on an old snapshot to reinstall everything with APK after a fresh start? I have a feeling that trying to upgrade the firmware while keeping the existing packages would be a bad idea now, if at all possible. With opkg, I used to use the following commands:
opkg list-installed > installed_packages.txt
opkg install $(cat /tmp/installed_packages.txt | awk '{print $1}')
That should still work just fine (assuming you replace a couple, like opkg becomes apk-mbedtls and luci-app-opkg becomes luci-app-package-manager). The switchover should be fairly transparent, not much changes other than the actual package manager used.
Of course you may want to wait a bit, and check first if all your packages have been built yet...
1 Like
Haven't looked into that, but as APK is now default in main/master, you shouldn't need anything else than clean master, I think.
1 Like
And apt for ubuntu…
perhaps there should be a soft link from opkg to apk on OS level, to avoid a gazillion "OMG! there's no opkg !" threads ?
2 Likes
Or to a script that says, "opkg is no longer, long live apk". But the tools that call it will freak out and crash, so you need something deeper.
I assume the "factory" tools have been prepped for apk, the rest will have to be fixed anyway, unless apk output, command line and functionality is 1:1 with opkg (I'm guessing it's not).
Um, yeah, that's a problem... 
Try ubus call rpc-sys packagelist on an apk snapshot (I've been working on that for a few days, but there are underlying issues that I have yet to overcome == ABI versioning is different so the package lists are incompatible).
And the snapshot builds aren't producing a parseable package index yet, so the ASU tools just fail ( Should have indexes soon.auc, owut and LuCI ASU app).
@elahl do you have some WIP patch? We can add the ABI version to apk and expose them if needed and no other way are possibile.