Thank you, I'm grateful for the work you and your colleagues have put into this.
3 Likes
Does the ABI version naming change mean that the red alert box on the APK wiki article should be updated? In particular, the second paragraph?
DO NOT USE
apk upgradeto update your packages!Doing so will sooner or later brick your device. Several library packages have as-yet unhandled ABI versioned names, which will cause a misconfiguration if you blindly upgrade them (
libubus,libustreamand many others).The safe way to upgrade all packages is to use one of the ASU clients: LuCI Attended Sysupgrade,
owutor Firmware Selector.
No, it doesn't. A better package manager doesn't magically fix deficiencies in the packaging (noticing ABI changes), nor design intricacies (r/o rootfs + overlay), nor immutable packages (e.g. kernel (OEM bootloader limitations) & libc & busybox & ...), nor does it magically retrofit 'enough' flash space for soname concurrency, nor.... It's just one piece in the puzzle, among many others.
To quite some extent these deficiencies are what makes OpenWrt possible on heavily ressource constricted hardware with very limited partitioning- and bootloader options in the first place. Just compare the minimum system requirements of OpenWrt vs Alpine vs Debian, Fedora, ...
EDIT: realistically, if you really want in-place upgrades comparable to e.g. Debian, your lowest common denominator for all supported devices would need to be:
- at least 5 times the minimum (flash-) storage requirements (and that's very much on the low side, in practice I don't think you'd succeed below ~1 GB usable space across all supported devices)
- a recoverable bootloader, so a means to toggle between at least two different kernel versions AND an ability for some kind of -easy- disaster recovery (in the sense of being able to boot from removable media or reflashing over serial or USB)
- a way for some flexibility in the storage partitioning, so no hardcoded assumptions (basically means eMMC, sdhc, SSD, HDD storage and a smarter bootloader than we actually have on most devices)
If you want OpenWrt to change into this direction, literally all supported devices would need to meet this as a hard minimum - right now, apart from x86_64 and the ARM SBCs (rockchip, RPi, sunxi) zero of the currently supported devices would meet these minimum requirements. Filogic might (provided they come with >=1 GB storage), with some changes on the bootloader side (they have USB based recovery) - apart from that, …crickets.
Having to cope with tiny main storage (>=8 MB), small RAM and ancient and very limited bootloaders with very limited interaction possibilities and bad recovery means just require making hard choices, which have consequences on 'ease of use' (and in-place upgrades just need to be sacrificed to allow a few dozen MB of flash).
It's easier to make (e.g.) Debian a decent router (on x86_64 or similar) - than to run Debian on the hardware OpenWrt typically deals with (actually impossible for >98% of all currently supported devices).
If you wanted to make OpenWrt fully support partial in-place upgrade, it would inevitably lose the ability to run on (almost all of-) the devices it currently supports - at which point it would just be another linux distribution without any distinguishing advantages (apart from a pretty GUI, which is the easiest thing in comparison, so 'just' start out with Debian and write a GUI).
9 Likes
Yes, the wording is out-of-date, but as you alluded and @slh explained in detail, the overall message remains the same.
1 Like
Been thinking about footprint on small devices again recently (https://github.com/openwrt/openwrt/issues/17108), so decided to check everything including the metadata, not just the bin and libs.
Not exactly the same, as my 24.10 test box has 273 packages installed, versus 299 on the snapshot one, but they are roughly the same.
# How many packages do we have installed?
$ opkg list-installed | wc -l
273
# How big is the actual package manager?
$ pkg-size -p opkg
'opkg' files:
155,131 /bin/opkg
109 /etc/opkg.conf
103 /etc/opkg/customfeeds.conf
0 /etc/uci-defaults/20_migrate-feeds
16 /lib/upgrade/keep.d/opkg
1,079 /usr/sbin/opkg-key
-----------
156,438 bytes 6 files in package 'opkg'
# How big is the installed package database?
$ du -h /usr/lib/opkg/ /tmp/opkg-lists/
3.3M /usr/lib/opkg/info
3.4M /usr/lib/opkg/
# How big are the indexes?
$ opkg update && du -h /tmp/opkg-lists/
968.0K /tmp/opkg-lists/
And a snapshot with above-linked issue fixed:
$ apk list --installed | wc -l
299
$ pkg-size -p apk
'apk-mbedtls' files:
91 /etc/apk/repositories.d/customfeeds.list
273,555 /usr/bin/apk
-----------
273,646 bytes 2 files in package 'apk-mbedtls'
$ du -h /lib/apk/
301.0K /lib/apk/db
257.0K /lib/apk/packages
560.0K /lib/apk/
$ apk update && du -h /tmp/cache/apk/
1.1M /tmp/cache/apk/
What we lose in binary size we make up for in much better compression of the metadata. Take this with a huge grain of salt though, as when you are on a squashfs system, most of that "3.4M" of opkg metadata will probably be in /rom for its whole lifetime and will be significantly compressed thus using a whole lot less flash space than 3.4M.
EDIT:
Fix merged, so small-flash snapshot users can sysupgrade, test and report their experience...
4 Likes
The apk-tools 3.0.0 stable version was just tagged a couple hours ago. This first production release of 3.0 will include some further shrinkage work on top of the RCs that we've been using, on top of the metadata (scripts.tar) reductions reported above.
Release - https://gitlab.alpinelinux.org/alpine/apk-tools/-/commit/9de54a44947b8bbf6b746c9c67bc2e18e4002f3c
Minimal applets - https://gitlab.alpinelinux.org/alpine/apk-tools/-/commit/88fe94b11b134759ff1238e7f65c60b793bc1532
Compressed help always - https://gitlab.alpinelinux.org/alpine/apk-tools/-/commit/819f999ab2c24c6d05cf2bcdb2ec96abe863bb46
The "minimal applets" version, which I'm pretty sure will be the default for OpenWrt's on-device version (the host version will need all the applets), removes a handful of tools that are generally unused on a production device as they deal with creation of packages and indexes.
adbgenadbsignconvdbconvndxdotindexmkndx
13 Likes
Now that apk 3.0 is released, the man pages have been published on the usual sites (previously, you had to format them yourself or read the raw .scd files):
The release notes for 3.0 are at https://gitlab.alpinelinux.org/alpine/apk-tools/-/releases/v3.0.0
Those of you who read through those and find anything useful, please consider updating/adding to the wiki articles:
4 Likes
@efahl Looks like apk 3.0.1 update has been released.
https://gitlab.alpinelinux.org/alpine/apk-tools/-/releases/v3.0.1
Here's another size check with all the compression tricks applied in the release code. We're down another 40k with the "minimal" applets applied and compressed internal help.
273,555 /usr/bin/apk apk-mbedtls-3.0.0_pre20251110-r2
229,360 /usr/bin/apk apk-mbedtls-3.0.1-r2
2 Likes
Here's a comparison of what went away pre- vs release. Note that the host version contains the full suite of applets (the one you'd create in buildroot, or gets packaged up in the SDKs and imagebuilders).
1 Like
I assume you have written the wiki pages? Thanks.
I have general question.
Besides installing an additional package after flashing, what use case do an OpenWrt user even have?
As I have learned and still do so,.if I have huge modifications, I reflash my devices. Installing packages is only done while prototyping and "develop" a new device config...
Besides internal documentation and neat hacks what should the user facing wiki page include?
Some of it, but by no means all.
Well, we'd need to define "user", which might be impossible. I use the package manager every day checking versions, chasing dependencies, locating source repos and all sorts of things. I'll often use apk fetch to grab a package, then apk adbdump to look at what it contains, that sort of thing.
If you are in the "set it up and forget it" mode, though, then you may never use the package manager beyond that first install -- in fact there has been discussion for years about having an OpenWrt variant without any package manager (simply use the ASU tools to create the image and do updates).
Good question. I'd say the OpenWrt wiki could or should be pretty minimal, since apk is a mainstream tool and has really excellent documentation that we don't have to maintain (woo!). As I link above, the arch wiki has all the man pages just as easily found as any OpenWrt docs, sort of negating any need for us to do anything more than write opkg -> apk transition hints.
1 Like
Just upgraded my NanoPi R5C gateway and GS308T switch from 24.10.4 to SNAPSHOT r32305-52fa3728e5. No apk update issues with the same upgrade on a NanoPi R5C gateway. GS308T result follows when I tried to update package lists on the GS308T (luci error message occurred first - terminal window is a second attempt after luci failed). Downgrading NanoPi R5C gateway back to 24.10.4 resolved the apk update issue on the GS308T still running SNAPSHOT. So perhaps something going on in SNAPSHOT unrelated to apk. SNAPSHOT was indeed a bit hit or miss on the R5C gateway (I couldn’t reach DuckDuckgo and a few other sites, but could reach Google, which resolved after the downgrade back to 24.10.4 on the R5C gateway as well).
The Unable to lock database looks like there are two instances of apk running simultaneously. Was that LuCI process running while you were doing command line operations?
EDIT
Yeah, as I suspected, I was able to reproduce:
$ ( apk update & ) ; apk update
ERROR: Unable to lock database: Resource temporarily unavailable
ERROR: Failed to open apk database: Resource temporarily unavailable
May well have been. I did wait until the error message displayed in Luci before trying from the terminal, but I did not click “Dismiss,” which may have left the Luci process active. In any event, any further gremlins will no doubt sort themselves out as the 25.12 rc’s start getting tested.
Note there are packages which can be upgraded without any downside e.g. PBR and which have frequent updates users might want to test.
So I am glad we can update, thanks to you and all who made this possible 
I believe the most common no-package-manager scenario would be to extend the life of old 4/32 or 8/64 devices. Leave out all of LuCI, package management and some other things, you can further extend the life of those old $5 routers.
Rough swag of what you save in the /rom image by ditching apk and luci:
$ tar cz $(find /lib/apk/ -type f) /usr/bin/apk | wc -c
292649
$ tar cz $(find /www/ -type f) | wc -c
371104
You can build a custom image right now using Firmware Selector, or from another "bigger" OpenWrt device with owut download --device X:X:X --clean-slate --remove 'luci apk-mbedtls' --add 'sqm blah blah...' (where X:X:X is the magic fingerprint for the target device).
2 Likes
I got a question 
With APK, will there be some kind of wrapper or installer for ipk?
I probably ask this for the wrong reasons, because on one hand I'm a advocate against mixing different package systems, but I found a reason why I think some sort of backwards compatibility is still very convient, maybe as utility form rather than a full manager.
Some routers like the Devolo magic2 next require external g.hn drivers for the powerline functionality which never will make through OpenWrt due to licenses, there are some attempts like extracting packages from the vendor firmware by a script which works fine, also for me as simple user.
But all those packages are in ipk/opkg manager format, I understand these can not be easily converted to APK because its not in source.
However if there is a chance to have a way to install older ipk packages that would be really nice, Now I can fix this with disabling apk and use opkg in my builder settings, but I guess this will not be a option for ever right?, is there some confirmation somewhere it will stay and not get deprecated/removed in favor for APK in the future?
I've never heard anyone mention it before, so I'd say it's unlikely.
But, since ipk is simply gzipped tar, you can disassemble them yourself. You lose the package manager's dependency checking, but getting the useful files out is pretty simple:
$ opkg download dnsmasq
Downloading https://downloads.openwrt.org/releases/24.10-SNAPSHOT/packages/x86_64/base/dnsmasq_2.90-r4_x86_64.ipk
Downloaded dnsmasq as ./dnsmasq_2.90-r4_x86_64.ipk.
$ tar xvzf dnsmasq_2.90-r4_x86_64.ipk
./debian-binary
./data.tar.gz
./control.tar.gz
$ tar xvzf data.tar.gz
./
./lib/
./lib/upgrade/
./lib/upgrade/keep.d/
./lib/upgrade/keep.d/dnsmasq
./usr/
./usr/sbin/
./usr/sbin/dnsmasq
... for like 20 more files.
If you need dependencies, those are in the control files:
$ tar xvzf control.tar.gz
./
./conffiles
./control
./postinst
./prerm
$ cat control
Package: dnsmasq
Version: 2.90-r4
Depends: libc, libubus20250102
...
2 Likes
Thanks this is usefull
I did not know it are archives, this can make it alot easier