The future is now: opkg vs apk

The package manager (apk or opkg) has no direct relevance to normal sysupgrade. The whole firmware gets updated and package manager has no role in it.

The possible hassle may come from package selection, if you use the quick&dirty firmware image cooking tools like owut, auc, attendedsysupgarde that may have inconsistensies in getting the right package manager included. But by default all the image should have right package manager of that release included in the image. (there has apparently been some trouble in the last few days reagrding that, but things should stabilize before 24.10.0 gets released)

And if you build your image from sources, it is right already now.

2 Likes

Just curious, why has OpenWrt not used opkg from the Yocto project, it seems to still be maintained? If the switch to apk is about the maintenance burden, that could have been an alternative.

The switch to apk will probably cause me major troubles, as I have a lot of code working around the limitation of opkg to do essentially distro upgrades/downgrades. Of course, I don't expect OpenWrt to take my troubles into account for the decision to switch to apk:-)

2 Likes

Did you check its size and that of its whole dependency chain (libarchive)?

I was able to use the firmware selector with customize packages drop down to build a main snapshot image for my R5C.

I had to add iptables-zz-legacy before luci-app-sqm; avahi-nodbus-daemon before ksmbd-avahi-service; and libjpeg-turbo and libffmpeg-full before luci-app-minidlna in my package list though.

I presume this means there are some missing dependencies with luci-app-sqm, ksmbd-avahi-service and luci-app-minidlna following conversion to apk?

Standard sysupgrade should be completely drama free, as older, pre-apk snapshots are mostly identical to 24.10. I even set up my local ASU server to provide access to 24.10-SNAPSHOT, and done owut upgrades back and forth between the two version without any issues. (This worked for that short window after the 24.10 tagging and before the switch to apk on main, but it provides evidence that sysupgrades will not be an issue.)

Yes, there's no config changes between the two at all, so the config is even more stable than the actual code.

Complain to google about their co-opting of apk, which has been in use by Alpine Linux since 2005.

1 Like

I think that has to do with the "virtual package" naming, which as you suspect breaks the dependencies.

Digging through /lib/apk/db/installed trying to understand things, I find (grossly abbreviated):

P:luci-app-sqm
D:sqm-scripts

P:sqm-scripts
D:iptables

P:iptables-zz-legacy
p:iptables

Where big "P" = package, big "D" = depends, little "p" = provides.

Since there could be multiple providers for iptables, maybe apk is getting confused and thus you must mention the -zz-legacy one before getting to sqm-scripts??? This was a bug in all of the ASU tools (FS, owut and server alike), where they all were sorting the package list before handing it off to imagebuilder, which with opkg caused exactly this sort of issue. I was hoping that apk would take care of it, but apparently not.

It could be that it's not apk but imagebuilder... If it's do apk add one-package for each package, rather than apk add all-packages, that might be the underlying cause; I'll have to dig into it when I get the time.

1 Like

How does APK handle config files inside packages during upgrades?

For example OPKG while updating luci-base pkg, saves the config inside the pkg to /etc/config/luci-opkg in order to NOT OVERWRITE existing /etc/config/luci .

apk appears to do something similar:

$ ls -la /etc/config/
...
-rw-r--r--    1 root     root          1017 Nov 12 03:58 luci
-rw-r--r--    1 root     root           687 Nov 14 15:01 luci.apk-new
1 Like

the issue will come up with normal building soon when we upgrade apk for a newer version which has arch validation. (we already had that for one day, but it was reveretd)

We have lots of script-only packages (most LuCI packages, database packages like 'ca-bundle' , script packages like 6in4 & 6rd4) that currently have PKGARCH:=all

Apk sets "noarch" as the always compatible arch, while in OpenWrt it is "all".
Looking at the apk source code, I think that the easiest way for us is to patch apk to also handle "all" like "noarch".

Based on https://gitlab.alpinelinux.org/alpine/apk-tools/-/commit/c1a3e69f24e235fc78f4dddb1f85fdf281464446 , the required change is likely just 3 lines: one new variable, setting that variable to be an "all" arch item, and adding an 'or' test for 'all' to the noarch check line.

I will test that later.

I would try to not add downstream patch in every way possible... Either we change and start setting noarch as the default arch or we add the noarch as the last entry in the arch file.

While I haven't tested it yet, it might even be possible to override $(PKGARCH) (in the USE_APK case) for all to noarch in include/package-pack.mk.

2 Likes


Not sure if this is the right place but I think this qualifies as an Alpine Package Keeper. :thinking:

6 Likes

That was my first thought, too.

Related APK upstream commit

1 Like

I see "uclient-fetch" is in the APK default packages list for most (all ?) of the targets.

Does this mean APK in Openwrt also uses uclient-fetch like OPKG?

OR does it use GNU wget or curl or something internal to APK itself?

It appears to do it's own thing, see
https://gitlab.alpinelinux.org/alpine/apk-tools/-/blob/master/src/app_fetch.c?ref_type=heads
and
https://gitlab.alpinelinux.org/alpine/apk-tools/-/tree/master/libfetch?ref_type=heads

Also, make sure to try out apk fetch coffee and apk fetch --force coffee. :joy:

4 Likes

Is uclient-fetch even required in APK firmwares, then?

Regarding the .APK package suffixes...

  • How many folks run Alpine vs Android?
  • How many devs are working on Android vs OpenWRT?

Seems like an unfortunate match...

As a short status report:

Upgrade a device with luci-attended-sysupgrade to the latest SNAPSHOT:
SNAPSHOT r28124-efc0c4666b
Manually removing opkg and adding apk.

Device is running fine.

Broken now:

Attended-Sysupgrade with:

TypeError: Cannot read properties of undefined (reading 'luci-app-attendedsysupgrade')

OWUT with:

owut - OpenWrt Upgrade Tool 2024.11.14~3b5e7bb9-r1 (/usr/bin/owut)
ERROR: ubus: Not found: Failed to invoke function 'packagelist' on object 'rpc-sys'
 from: 'ubus call rpc-sys packagelist { "all": true }'
This is a bug in 'owut/2024.11.14~3b5e7bb9-r1', please report at
  https://github.com/efahl/owut/issues
...

Reported at: https://github.com/efahl/owut/issues/22

apk:

apk update
fetch https://downloads.openwrt.org/snapshots/targets/ipq40xx/chromium/packages/packages.adb
WARNING: updating and opening https://downloads.openwrt.org/snapshots/targets/ipq40xx/chromium/packages/packages.adb: No such file or directory

...

The files are there, but apk is not able to fetch them.

Any issue report needed for this?