That is correct, apk doesn't know how to install *.ipk files. If you are using the standard OpenWrt buildroot tools for creation of packages, it should be completely transparent.
For example, to test my owut packaging, I simply git checkout openwrt-24.10 for the opkg version, then git checkout main to build the apk one (to test, I scp them to their respective OpenWrt VMs, install and run...).
Packages need to be rebuilt regularly anyways, at least anything but the most trivial shell scripts (and even those fell over iptables being replaced by nftables in the past, procd/ ujail/ seccomp changes, etc. pp.) has dependencies on various libraries (starting with musl). Libraries regularly (on the pace of every few weeks to every few months, depending on the libraries in question) see soname bumps and library transitions, so there's nothing new about having to actually maintain (and regularly update/ rebuild) binary packages you're offering. From this angle, it's business as usual and a complete non-issue (there are very few adaptions required for apk on the packaging level, having to follow stricter rules for version numbers is among the biggest ones).
Good catch!
It was suggested I post/pose this question to the larger audience here, as it could affect other devices:
luci-app-statistics (actually collectd) doesn't seem to be collecting statistics anymore
apk fix will delete these for you too.
If you add or delete packages from /etc/apk/world, apk fix will also install and uninstall packages to converge to the new world definition.
The concept of the world file is a pretty important one in apk, and definitely worth mentioning in the documentation (or properly point people to the relevant man page). This file is a list of desired packages, and apk will install and uninstall packages so that the system state converges to the list. This is the very foundation of how it works. apk add actually adds a package to that list, and then installs any that are not present. apk del removes a package from that list, and only uninstalls it if it’s not a dependency for anything else.
I'm having an issue with a custom build on the LinkSys HomeWrk router and was wondering if its only me. I'm completely new to this so I might be my fault.
The issue is that after installing any package, all other attempts to install anything else fails with the below error. If I uninstall the first package, I'm allowed to install another.
The other interesting thing is that if I do multiple packages at once, that works. Is this a known issue?
root@OpenWrt:~# apk add adblock-fast
(1/1) Installing adblock-fast (1.1.2-r10)
Executing adblock-fast-1.1.2-r10.post-install
OK: 36 MiB in 183 packages
root@OpenWrt:~# apk add luci-theme-openwrt-2020
ERROR: unable to select packages:
adblock-fast-1.1.2-r10:
error: uninstallable
arch: all
satisfies: world[adblock-fast]
root@OpenWrt:~# apk del adblock-fast
(1/1) Purging adblock-fast (1.1.2-r10)
Executing adblock-fast-1.1.2-r10.pre-deinstall
Stopping adblock-fast service... OK
Removing rc.d symlink for adblock-fast... OK
OK: 36 MiB in 182 packages
root@OpenWrt:~# apk add luci-theme-openwrt-2020
(1/1) Installing luci-theme-openwrt-2020 (24.322.80622~a403707)
Executing luci-theme-openwrt-2020-24.322.80622~a403707.post-install
OK: 36 MiB in 183 packages
root@OpenWrt:~# apk add adblock-fast
ERROR: unable to select packages:
luci-theme-openwrt-2020-24.322.80622~a403707:
error: uninstallable
arch: all
satisfies: world[luci-theme-openwrt-2020]
root@OpenWrt:~# apk del luci-theme-openwrt-2020
(1/1) Purging luci-theme-openwrt-2020 (24.322.80622~a403707)
Executing luci-theme-openwrt-2020-24.322.80622~a403707.pre-deinstall
OK: 36 MiB in 182 packages
root@OpenWrt:~# apk del luci-theme-openwrt-2020 adblock-fast
OK: 36 MiB in 182 packages
root@OpenWrt:~# apk add luci-theme-openwrt-2020 adblock-fast
(1/2) Installing adblock-fast (1.1.2-r10)
Executing adblock-fast-1.1.2-r10.post-install
(2/2) Installing luci-theme-openwrt-2020 (24.322.80622~a403707)
Executing luci-theme-openwrt-2020-24.322.80622~a403707.post-install
OK: 36 MiB in 184 packages
root@OpenWrt:~#
root@OpenWrt:~# apk fix
ERROR: unable to select packages:
adblock-fast-1.1.2-r10:
error: uninstallable
arch: all
satisfies: world[adblock-fast]
luci-theme-openwrt-2020-24.322.80622~a403707:
error: uninstallable
arch: all
satisfies: world[luci-theme-openwrt-2020]
root@OpenWrt:~#
Look at this post.
I think this worked. Thank you.
I had the same issue even before apk. Not sure hiw I resolved it tough, but please see this: https://github.com/openwrt/luci/issues/6172
I do not think it is related to apk.
Kr
K
@ka2107 , ref to your post above, The future is now: opkg vs apk - #170 by ka2107
A new apk-related issue has been logged: https://github.com/openwrt/openwrt/issues/17033
tldr: Upon re-installing a package that has a config file, you get a new /etc/config/pkg.apk-new (opkg created /etc/config/pkg-opkg). The dash in the file name causes uci to fail in various way, so you must manual intervene by removing or renaming the .apk-new file.
Edit:
My current theory is that it's the dash-after-dot in the apk-new files, as uci gets stubby.apk-new, parses it at the dot into stubby for the file name and apk-new for the section name and then borks, either on the missing section, or the malformed section name (section names should not have dashes, they should use underscores). Not sure which is the root cause yet, but the effect is the same in that various uci xxx commands fail and cause mayhem.
Think you just solved the problem with luci-app-statistics, too!
see update at bottom
AND my NextDNS problem, too!
Update: I deleted both files and rebooted the router, made no difference. Statistics page still shows error that it's not recording any data.
The cause of The future is now: opkg vs apk - #127 by ka2107 issue was https://github.com/openwrt/openwrt/issues/16953
# cat /etc/apk/arch
x86_64
which has been fixed by https://github.com/openwrt/openwrt/pull/17015
Now it is
# cat /etc/apk/arch
aarch64_cortex-a53
It has been my experience that luci-app-statistics can be wonky if there are config sections for plugins that are not installed. This often happens after a firmware update. Not an issue if attended sysupgrade is used as all the currently used plugins will be there afterwards as well.
Yeah I've seen this as well, just open logread when you restart collectd and see what fails its pretty straightforward debug
Why uclient-fetch is not a dependency of apk? It is a dep for opkg...
│ Symbol: PACKAGE_uclient-fetch [=n] │
│ Type : tristate │
│ Defined at tmp/.config-package.in:118135 │
│ Prompt: uclient-fetch..................... Tiny wget replacement using libuclient │
│ Location: │
│ -> Network │
│ (1) -> uclient-fetch..................... Tiny wget replacement using libuclient (PACKAGE_uclient-fetch [=n]) │
│ Selects: PACKAGE_libc [=y] && PACKAGE_libuclient [=y] │
│ Selected by [n]: │
│ - MODULE_DEFAULT_uclient-fetch [=n] && TARGET_PER_DEVICE_ROOTFS [=n] && m && MODULES [=y] │
│ - PACKAGE_opkg [=n] │
│ - PACKAGE_6in4 [=n] && IPV6 [=y]
Because it is a globally included default in any case.
It can naturally be disabled in .config, so using the same full .config for too long can cause some items to deviate from defaults, especially when major changes are being made)
I guess trouble may arise if using attendesysupgrade/auc/owut etc. tools if the "starting package set in the old image" is faulty
Which means one can remove it, as they see it's not required by anything, and then break their installation (ask me how I know :P)
What you said is true for opkg too, and for opkg it is a dep...
One shouldn't remove default packages, unless you really know what you are doing. They are not there just for fun although it may seem that "it's not required by anything"
Can't say I do (I only roughly know...) but I still don't get why for opkg it was a dep and for apk it's not. Sorry for nitpicking...