The future is now: opkg vs apk

Well, the timeline goes like:

For apk it has likely not been added, as it is already in the global "always there" defaults.

Thank you for the clarification.

I always thought about defaults as "most people would like these" rather than "removing these can break your system".
In particular, switching to openssl instead of mbedtls is kinda probably because of libustream-mbedtls being a default.

1 Like

apk should actually depend not directly on uclient-fetch, but on a wget provider, one of which is uclient-fetch (another is wget-ssl)

Since apk can't operate properly without a wget provider installed, this is a bug in the apk packaging, you should log an issue.

# apk info --depends apk*
apk-mbedtls-3.0.0_pre20241113-r1 depends on:
libc
libmbedtls21
zlib
2 Likes

Defaults is a build thing, not a packaging thing. Defaults simply give you a starting point that says "use these and you'll get a running OpenWrt". They should not have any impact on dependencies or package interaction.

2 Likes

Well, none of our packages declare dependency to uci, although most packages use uci for config.
UCI is similarly just one of the default packages.

1 Like

And yet they should...

It might be a good time during all of this other thrashing to fix the dependencies on everything, take full advantage of the apk switchover and let it do its job as designed.

One of my current thoughts is to also get rid of the ABI-versioned package names, and just use apk constraints to manage the dependencies properly (my archeological digging strongly suggests that the ABI-names are an artifact of opkg's lack of functionality in this regard).

2 Likes

Should I file an issue for this as well? :stuck_out_tongue:

2 Likes

Not really.
uci is quite rightly assumed to be always there.
Otherwise it wouldn't be any "OpenWrt" any more.

some "wget" depedency for apk is much more relevant to add.
But uci, ubus, ubox etc. are the really deep-core packages that make OpenWrt

And yet if you check dependencies on kernel (opkg whatdepends or apk info --rdepends), you see many dependencies.

I don't see how uci is different than any other package, you shouldn't be able to just say opkg remove uci or apk del uci and have it actually remove uci and not complain... That's the whole point of having a package manager, to protect yourself from such gaffs, and the only way to do that is to properly declare all dependencies.

2 Likes

Shouldn't they be added as dependencies to base-files then (similar to procd pkgs)?

Something like that, but base-files has the same issue as uci, nothing depends on it...

$ opkg whatdepends base-files
Root set:
  base-files
What depends on root set

and

$ apk info --rdepends base-files
base-files-1637~2784f78c6c is required by:
1 Like

AFAIK base-files, kernel and libc are non-upgradable and (maybe?) non-removable packages.

So I think just making uci, ubus and ubox as dependencies for base-files should work.

Also how about netifd, logd, urandom-seed and urngd, are they needed in ALL OpenWrt firmwares?

You're looking at https://github.com/openwrt/openwrt/commit/451e2ce006eaba5341d7e33ac587719c3bf18701 ? Doesn't seem to do anything. There were some discussion (on apk issues???) about making packages "required", i.e., undeletable, but I can't find that right now.

$ apk del --simulate base-files
(1/5) Purging base-files (1637~2784f78c6c)
(2/5) Purging fwtool (2019.11.12~8f7fe925-r1)
(3/5) Purging openwrt-keyring (2024.11.01~fbae29d7-r2)
(4/5) Purging procd-seccomp (2024.11.13~7330fa55-r1)
(5/5) Purging usign (2020.05.23~f1f65026-r1)
OK: 60 MiB in 253 packages
2 Likes

Yes, that's the commit I was thinking about.

Oh, should have added an example of something with properly defined dependencies:

$  apk del --simulate kernel
World updated, but the following packages are not removed due to:
  kernel: kmod-r8169 kmod-igb kmod-dwmac-intel kmod-amd-xgbe kmod-igc kmod-e1000e kmod-ixgbe kmod-tg3 kmod-bnx2 luci-app-sqm kmod-nft-offload nftables dnsmasq-full ppp ppp-mod-pppoe kmod-e1000
          conntrack kmod-button-hotplug kmod-amazon-ena kmod-fs-vfat ss kmod-forcedeth

I haven't checked if apk can model ABI dependencies without that yet, but massive packaging changes are better delayed until opkg is really dead (when 23.05.x becomes EOL, assuming that apk still makes it into 24.10.x, which I wouldn't take for granted, yet), as these would make backporting much harder.

Would you still be able to install multiple ABI versions of a library side-by-side, or would you have to upgrade all packages that depend on that library at the same time you upgrade the ABI version of the library?

1 Like

can apk be made to work with wolfssl?

why this new change, when something is good and stable, then someone comes and refactor to use apk instead of opkg, what is the reason? just playing? generating more work?

@patrikx3:

4 Likes