The future is now: opkg vs apk

stangri · 2024-11-16T22:20:48.263Z

The untrusted signature is usually overcome with --allow-untrusted in the CLI. I'm trying to figure out how to add my signature to the build system so that hopefully, after importing a public key into a live OpenWrt install everything is trusted again, but setting up a repo is higher priority.

UPDATE: rebuilt binaries and added the packages.adb.

sfx2000 · 2024-11-17T03:35:56.160Z

This likely is a point of confusion...

There are many APK formats - first thing I saw was Android and their apk format...

Not sure why this extension was decided on...

drut · 2024-11-17T09:49:21.622Z

How will upgrade (sysupgrade) from 2 months old snapshot to 24.10 stable look like? Will it be possible with leaving current config in-place?

hnyman · 2024-11-17T09:54:38.530Z

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.

jan · 2024-11-17T10:41:23.175Z

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:-)

slh · 2024-11-17T10:56:47.832Z

jan:

opkg from the Yocto project,

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

eginnc · 2024-11-17T13:39:16.780Z

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?

efahl · 2024-11-17T15:29:28.580Z

drut:

How will upgrade (sysupgrade) from 2 months old snapshot to 24.10 stable look like?

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.)

Will it be possible with leaving current config in-place?

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

efahl · 2024-11-17T15:30:26.527Z

sfx2000:

There are many APK formats - first thing I saw was Android and their apk format...

Not sure why this extension was decided on...

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

efahl · 2024-11-17T15:53:34.165Z

eginnc:

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 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.

ka2107 · 2024-11-17T17:54:01.239Z

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 .

efahl · 2024-11-17T18:25:01.716Z

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

hnyman · 2024-11-17T21:17:07.045Z

Ansuel:

mhhh apk have some commit changing the usage of the arch file... but anyway is it really correct to set all?

What arch should be allowed in the system?

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.

Ansuel · 2024-11-17T21:30:33.017Z

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.

slh · 2024-11-17T21:30:42.442Z

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.

Gopten · 2024-11-17T21:42:46.930Z

AlpinePackageKeeper672×865 43.6 KB

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

efahl · 2024-11-17T23:06:27.013Z

slh:

override $(PKGARCH) (in the USE_APK case) for all to noarch in include/package-pack.mk.

That was my first thought, too.

ka2107 · 2024-11-17T23:17:21.243Z

Related APK upstream commit

GitLab

db: print message when a file is written to .apk-new (d86afdef) · Commits ·...

If there is no indication of a .apk-new file being created, users may mistakenly believe that the installation was successful, even if apk did not write to the file. With...

ka2107 · 2024-11-17T23:26:11.949Z

hnyman:

I am not sure if apk uses some built-in download component, or an external wget style helper, like opkg did.

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?

efahl · 2024-11-18T00:10:59.450Z

ka2107:

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.