Just to confirm, the skeleton was one with apk-mbedtls? And the mbedtls version of apk is still installed, but now apk-openssl is the "working" version? (I'm curious as to what got deleted and what was just abandoned and left in place.)
yes, the skeleton was the one from downloads.openwrt.org .
it has apk-mbedtls, libustream-mbedtls, and wpad-basic-mbedtls installed packaged.
after the steps outlined above, there were no apk binaries. when i ran
apk list --installed *mbed*
the list was emply.
so the
apk del *mbed*
effectively removed apk-mbedtls as far as i can tell.
i'm not at my openwrt environment right now but i confirmed this a few times this AM.
i did have to reboot after a number of package installs to get everything working correctly.
1 Like
Great topic that i missed....
My 5 cents. I still missing two features that neither opkg nor (I think so) apj could solve:
-
be able to install kernel modules from site upon my customized kernel. Sometimes, I'm too lazy to feed such module from my own build. Let me break my system in whatever way I want!
-
Be able to separate packages installed in firmware rootfs and those in overlay. So I will know what deleting of packages will lead to the actual decrease in used space...
There's a new feature in the pipes for apk: JSON formatted output from the adbdump applet. See today's commit at https://gitlab.alpinelinux.org/alpine/apk-tools/-/commit/fe4876bd3a4edf21fea02f2b14e0029959dbb9b3 for details.
Since apk adbdump works on any v3 file or index, this will allow easy parsing of any .apk or .adb file's metadata using standard tools like jsonfilter.
1 Like
I'm not sure whether this is the right place to have this discussion but am I the only person who doesn't feel like JSON output is easy and cost-effective (lines-of-code-wise) to work with, at least with built-in json parsing tools on OpenWrt? I'm certainly not the most experienced user of jshn because till recently, I've been always able to parse json with sed. A few days ago was the first time I actually had no choice, so I created this contraption, which required a lot of patience on my part, and the resulting code has 18 calls to jshn and its functions, which eventually populate 4 variables for me. (There is more stuff going on there but I'm ignoring it for this matter)
Now every other OpenWrt project which needs this data would need to use a similar number of lines. Wouldn't it be better, easier and much more cost-efeective in terms of LOC count to just have a simple API, something like:
dnsmasq_get_instances INSTANCES
for instance in $INSTANCES; do
dnsmasq_get_instance INDEX RUNNING IFACES CONFDIR "$instance"
<do_actually_useful_stuff>
done
I've been thinking this for some time and I'm curious what others think.
Or a little more selective, just --depends in place of --all (note also --rdepends for going in the "upstream" direction).
1 Like
Agreed, jshn is pretty painful, seems like a legacy solution that needs some rework, but it's sooo pervasive.
Have you played with jsonfilter and ucode? When I write OpenWrt-specific (i.e., non-portable for the most part) code these days those two do an excellent job for me, and are "guaranteed always there" (fw4 is written in ucode, and jsonfilter is a dependency of base-files). When scripting in sh, and if you only need to read json, then jsonfilter is definitely the easiest thing to use.
1 Like
I played just a bit with jsonfilter but didn't think it was the way to go because the effective way to use it LOC-wise is something like
info=$(/etc/init.d/dnsmasq info)
instance_index=$(printf %s "$info" | jsonfilter <options>)
So essentially getting a value necessitates a call to a binary, and more importantly creating a subshell and a pipe. Knowing how inefficient this is in terms of performance, I can't make myself do it...
I just recently became aware of the existence of ucode. Also your ucode code (pun half-intended) is quite pretty. Unfortunately, to my understanding, it uses a [java|ECMA]script syntax, which I don't really know because every time I tried to learn js, I got this nasty feeling of aversion 
Is there some learning resource you think could be good for someone like myself?
Anyway, in the meantime shell scripts continue to exist and thrive in the ecosystem, and probably will continue to. So I wonder, if let's say I put my time into implementing above API, lets say as an addition to the dnsmasq init script script, would it get merged? (assuming the code quality is good)
Anton, could you create a new thread "JSON tools on OpenWrt" or something like that? I'll reply there...
1 Like
@efahl may I suggest to update your top post here just to say "...then it is strongly suggested you move to 24.10 branch."
Since snapshots are not longer best for that branch. That should be good enough to imply RCs/latest builds.
1 Like
I agree. Done.
A quick question. When the transition takes place from opkg to apk in stable releases, will naming requirements for packages also change? The reason I am asking is that when extracting a list of packages on device to compile a custom list, cleaning up the date annotations of packages can be rather annoying (i.e. from libubus20240130 to just libubus *as a fictional example).
The naming/versioning changed already in main/master. All package names/versions are already APK compatible (or they would not compile in the buildbot).
So, when the next stable release 25.xx (?) gets branched, it is already ok.
The ABI versioning is a bit different thing, but shouldn't cause much havoc.
2 Likes
Yeah, those aren't really "dates" per se, but rather ABI versions that just happen to be derived from dates (see jansson4 for an example that looks different). That said, this is all part of the ongoing ABI-versioned naming scheme that's being worked on and will be fixed loooong before apk gets into an OpenWrt release.
You can follow the work being done on the underlying apk parts here: https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/11066 Once that gets done, we need to fix up the ubus packagelist call to propagate it to the ASU tools.
1 Like