Interesting and practical points made thanks. I'm not a dev here but would like to add that from a high level moving up to major upstream projects is for long term support. No single team can mantain all parts of an OS. Think about the large improvements made in the last few years:
Linux kernel - latest LTS
GCC - latest
client side/ javascript based web UI
DSA
nftables
apk
The huge array of modern hardware and wifi 6 / 7 coming with Linux updates. All these big improvements positioned this from "another router firmware project", to "the premier Linux networking distro". It beats BSD based projects like pfSense. Savvy tech people will choose devices to buy that has good OpenWrt support now.
Stagnation is death in tech. Happy to see this project doesn't stagnate
I've been following this thread since it began. This is the Talk about Documentation forum, but it feels like out of the 261 posts in this thread so far, only about 5-10 (ballpark, I've not actually counted) are actually discussing the WIP documentation for how to use APK on OpenWrt, how the commands differ from opkg, etc. The ones that do discuss it are mostly at the very beginning of the thread, before the APK switch happened in main.
Would it make sense for moderators to move or split this thread, so that documentation can be discussed without getting lost?
Don't see a reason to split, the transition was so smooth there isn't much to talk about now. Within a couple weeks since main switched apk is working great. I'd expect this thread to be linked to for years as people keep coming back asking about apk rather than searching for it
@ansuel, I just submitted https://github.com/openwrt/rpcd/pull/10 as a preliminary solution to the missing ubus call rpc-sys packagelist. If you have time, I would very much appreciate a review.
Agreed. The hard part is the social side, getting everyone to agree that this is a good idea is much harder than figuring out how to remove the suffixes. I've been experimenting with some isolated changes in the package makefiles, and think that this can be done completely transparently wrt the actual packages themselves (the pkg<suffix> is created -or not- in only 2-3 places there).
No, you would not be able to install two versions of the same package as the identical names would conflict. Do you have a use case where you'd want to descend into "DLL hell" with something like this? It seems very unlikely to be useful in such a walled garden as OpenWrt where you simply rebuild the whole image and keep everything simple and consistent.
That was discussed and it was decided to keep it all in one place for discoverability. Since it had already accumulated a lot of information, it sort of became the de facto "all about apk" thread (instead of my original intent, which was "collect use info for the wiki how-to").
Nobody 'wants' that, but libraries like wolfssl might require that during in-place upgrades, when the depending packages haven't all been rebuilt for the new ABI, yet. That is the problem with upstreams like wolfssl, who don't commit to reasonably stable ABIs and change them just-cause.
Yeah, there's always "that guy." It might sound harsh, but maybe apply the same ruthlessness to crappy packages that we do to 4/32 devices: "get rid of it and use a better one". It doesn't really make sense to me to spend a lot of effort modifying the mainstream tools to accommodate fringe cases, it just messes up too many widely spread bits with special case code.
For example, my PR fixing the ubus call rpc-sys packagelist "works", but produces unusable results, because there is no ABI info in any of the packages, "installed" db or "world" file. We're going to have to hack up the buildroot package scripts, rpc code and probably patch apk itself to add this. (The apk devs have already refused a PR to add ABI metadata upstream: https://gitlab.alpinelinux.org/alpine/apk-tools/-/merge_requests/152)
On the one hand is your example command quite specific and 'uncommon', on the other hand do (currently) many programs (e.g. luci-app-packagemanager) decide what to use based on the presence of opkg XOR apk executables, so adding a helper of this kind would actively break important tools.
The OpenWrt developers have decided to use opkg in 24.10, remove the option to build it with APK support, and postpone the APK switch in release branches until the 25.xx series. This will give them more time to work out any remaining issues with it in OpenWrt main.
Since we are not switching to apk in 24.10, can we use apk v2 or apk v4 or other names (in short, non-adb format) in 25.xx? I think adb (apk v3) is not a good design.
I don't think there's any chance that OpenWrt developers are going to suddenly revert to apk v2. If you have valid, detailed, and constructive feedback and factual analysis about problems with apk v3 and how exactly it could possibly be improved upon in a future apk v4, the place to discuss that is in the Alpine Linux community, such as on the apk-tools mailing list. See also: contributing to Alpine Linux.
However, from what I've read, the Alpine Linux distribution itself hasn't yet switched to apk v3. I imagine it'll be quite a while before a potential apk v4 comes around, and OpenWrt 25.xx will most likely use apk-mbedtls v3.
Disclaimer: I am neither an OpenWrt nor an Alpine developer.
