I've mocked up the ubus call in ucode on snapshot, but the ABI issue is still lingering. It probably needs to be reflected in that index.json patch, too, as previously we only worked the package names without the ABI suffixes.
(Oh, and on my clean-build-VM the /etc/apk/world file contains all of the installed packages, not just the top-level ones, but that's a separate issue.)
#!/usr/bin/ucode -S
// vim: set noexpandtab softtabstop=8 shiftwidth=8 syntax=javascript:
// Rough outline of ubus call rpc-sys packagelist in ucode
let all = false;
import * as fs from "fs";
let deps = {};
let line;
let pkg = null;
let ver = null;
// https://wiki.alpinelinux.org/wiki/Apk_spec
let db = fs.open("/lib/apk/db/installed", "r");
while (line = db.read("line")) {
line = trim(line);
if (! line) {
deps[pkg] = { top:false, ver };
pkg = ver = null;
}
else {
let prefix = substr(line, 0, 2);
let tail = substr(line, 2);
switch (prefix) {
case "P:":
pkg = tail;
break;
case "V:":
ver = tail;
break;
}
}
}
if (pkg != null) print("EEEEEEEEERRRR\n", pkg);
let world = fs.open("/etc/apk/world", "r");
while (line = world.read("line")) {
line = trim(line);
if (! (line in deps)) {
printf("ERROR: %s not in packages\n", line);
continue;
}
deps[line].top = true;
}
let packages = { packages: { } };
for (let pkg, info in deps) {
if (all || info.top) {
packages.packages[pkg] = info.ver;
}
}
printf("%.2J\n", packages);
I've wondered about just exposing an API via, say, libapk, that would let us call list or adbdump without an exec. (I'm also interested in adding a "whatprovides" rpc call, since owut does that to show that dnsmasq-full is the package that provides dnsmasq).
Ok, that's sort of a side issue for me that I can figure out and optimize later. The real issue is getting an ABI-less version of the package names, so if you could add some ABI info to the DB, that would satisfy my immediate needs.
Some examples. Here's one with a suffix that is due to ABI (generated via adbdump), and naively you'd think "Just use the provides: name", but...
The provides field is actually that and if we were to substitute it for the following one, then we've broken the install.
- name: dnsmasq-full
version: 2.90-r3
hashes: |
0df852f84b27cf139c07d0aadc6df775478b27876fc4abdc00414ac428fd5fe3
description: |
It is intended to provide coupled DNS and DHCP service to a LAN. This is a fully configurable variant with DHCPv4, DHCPv6, DNSSEC, Authoritative DNS and nftset, Conntrack support & NO_ID enabled by default.
arch: x86_64
license: GPL-2.0
origin: feeds/base/network/services/dnsmasq
url: http://www.thekelleys.org.uk/dnsmasq/
installed-size: 464 KiB
file-size: 201 KiB
depends: # 5 items
- libc
- libnetfilter-conntrack3
- libnettle8
- libubus20241020
- nftables-json
provides: # 1 items
- dnsmasq
(I think this is a historical artifact of opkg not having any ABI constraints, so back in the day, devs would make the package name contain a version number libubox20240329 so you couldn't brick things as easily by just saying opkg upgrade everything wooo!!! But now that bites us because you can't just apk add libubox, even though apk knows how to do the right thing wrt versions. I know, I know, part of a wider cleanup...)
Hi, first of all, thanks for making OpenWrt's packaging more functional.
I've read this post all the way to the bottom, but still missing the point of the big transition from opkg to apk. This post by @slh pointed out that opkg can't handle a multi-feed-aware setup and it makes sense. I assume there are more past discussions over the transition to pay the high cost to overcome other cons of opkg.
Can anybody tell me the point (pros/cons, and a simplified discussion history, if any) with a bulleted list?
if I'm built/compiled the OpenWRT firmware from snapshot, the last was a month ago, if I do a git pull to get latest OpenWRT sources will them compile and build a firmware image successfully?
or now I need to do extra steps configure apk package signing?
It doesn't matter for sure, and I'm not against apk. I would like to understand what's the beginning to think of the transition and how it evolved. As I see this commit, it all started in 2021, and tracing the ML to the point is pretty hard. So I just wanted to ask to knowledgeable people about this. Sorry for taking your time for this dumb question, but other people would like to know this too.
root@openwrt:~# apk update
fetch https://downloads.openwrt.org/snapshots/targets/mediatek/filogic/packages/packages.adb
WARNING: updating and opening https://downloads.openwrt.org/snapshots/targets/mediatek/filogic/packages/packages.adb: No such file or directory
fetch https://downloads.openwrt.org/snapshots/packages/aarch64_cortex-a53/base/packages.adb
WARNING: updating and opening https://downloads.openwrt.org/snapshots/packages/aarch64_cortex-a53/base/packages.adb: No such file or directory
fetch https://downloads.openwrt.org/snapshots/targets/mediatek/filogic/kmods/6.6.60-1-0561031e21f60f05c8f540bffb723036/packages.adb
WARNING: updating and opening https://downloads.openwrt.org/snapshots/targets/mediatek/filogic/kmods/6.6.60-1-0561031e21f60f05c8f540bffb723036/packages.adb: No such file or directory
fetch https://downloads.openwrt.org/snapshots/packages/aarch64_cortex-a53/luci/packages.adb
WARNING: updating and opening https://downloads.openwrt.org/snapshots/packages/aarch64_cortex-a53/luci/packages.adb: No such file or directory
fetch https://downloads.openwrt.org/snapshots/packages/aarch64_cortex-a53/packages/packages.adb
WARNING: updating and opening https://downloads.openwrt.org/snapshots/packages/aarch64_cortex-a53/packages/packages.adb: No such file or directory
fetch https://downloads.openwrt.org/snapshots/packages/aarch64_cortex-a53/routing/packages.adb
WARNING: updating and opening https://downloads.openwrt.org/snapshots/packages/aarch64_cortex-a53/routing/packages.adb: No such file or directory
fetch https://downloads.openwrt.org/snapshots/packages/aarch64_cortex-a53/telephony/packages.adb
WARNING: updating and opening https://downloads.openwrt.org/snapshots/packages/aarch64_cortex-a53/telephony/packages.adb: No such file or directory
7 unavailable, 0 stale; 207 distinct packages available
Any ideas what I might have borked? Or additional debugging steps?
I can ping google.com so I don't think it is is connectivity related.
It's a server side error. As you can see, index files don't exist on the server.
As for the reason, it's probably "work in progress" or the buildbot has yet to process that target.
Just wait for now, there's nothing you can do.
I am able to download the file with wget so the files seem to exist which is what confused me. I'll hold tight be now though! It also worked initially and then stopped working after the fact.
Probably it's not a bad idea to announce the change to apk on top of the forum because I see more and more people not aware of the change and some of them even broke their routers trying to use the ASU to generate images and flash them to their routers.
