package-manager: migrate to apk-tools JSON API

[Konstantin-Glukhov]

Replace legacy opkg status parsing with native apk-tools JSON queries. This modernizes the backend calls and improves dependency resolution.

• Implement 'apk query --format json' for package data retrieval.
• Add robust regex for versioned dependencies (e.g., name>=version).
• Update version comparison to handle APK date-based revisions.
• Fix label-input associations to resolve accessibility warnings.
• Retain deprecated opkg fallback logic for LuCI master.

NOTE: The change rational is discussed in openwrt/openwrt#22512

• This PR is not from my main or master branch 💩, but a separate branch ✅
• Each commit has a valid ✒️ Signed-off-by: <my@email.address> row (via git commit --signoff)
• Each commit and PR title has a valid 📝 <package name>: title first line subject for packages
• Tested on: (ARMv7, OpenWrt 25.12.1, chrome/firefox) ✅
• Description: (describe the changes proposed in this PR)

[systemcrash]

Two comments: we need to maintain support for opkg until 24.10 goes out of support, in case anything gets backported to 24.10. It looks like opkg gets removed here.

I'd like an OK from at least @efahl also.

[efahl]

I'm still digesting it before review.

And although my conceptual opinion is that this is a good cleanup, getting rid of a bunch of old junk, I think we need some input from @Ansuel as he's the one who migrated from opkg-only to dual package manager support, and surely has some opinions on this.

[Konstantin-Glukhov]

I'm still digesting it before review.

And although my conceptual opinion is that this is a good cleanup, getting rid of a bunch of old junk, I think we need some input from @Ansuel as he's the one who migrated from opkg-only to dual package manager support, and surely has some opinions on this.

I was not aware that 24.10 needs to be maintained in the master branch. I will merge the prior stuff back.

[efahl]

I was not aware that 24.10 needs to be maintained in the master branch. I will merge the prior stuff back.

I'd wait a bit on that, it may be the case that this is fine for master and 25.12, and that we can just maintain 24.10 package manager independently.

(I personally would like that, but it's not my call. 🙂)

[Konstantin-Glukhov]

I was not aware that 24.10 needs to be maintained in the master branch. I will merge the prior stuff back.

I'd wait a bit on that, it may be the case that this is fine for master and 25.12, and that we can just maintain 24.10 package manager independently.

(I personally would like that, but it's not my call. 🙂)

OK, if it is decided to have the dual functionality (opk+apk), then I have the change is tested and staged for a commit.

[systemcrash]

Retain opkg for now, please.

[XCas13]

@Konstantin-Glukhov Please also consider changing install) action="add" ;; to install) action="add --allow-untrusted" ;; for APK in package-manager-call. This will make the "Download Package" button useful again 🙂 as I described it in #8482. Unless the package developers/maintainers have any objections to this. Don't want to create another PR with changes that will conflict to yours 🙂

[systemcrash]

to install) action="add --allow-untrusted" ;; for APK in package-manager-call

If anything, this should probably have a checkbox for this flag, so user's don't blindly install harmful code.

[Ansuel]

I'm against allow untrusted... also the APK are now also signed so official .apk should also work from the upload page.

[systemcrash]

Fair. I figure the problem is apk from external repos (I've been contemplating a 'repo' file format that one can drag+drop onto the repokeys page, so adding repos would be easy) or from their own build environment.

[XCas13]

There is no point to use Upload Package for trusted packages, because it's simply possible to install them let's call it "official way". The "Upload package" button is really used for uploading untrusted packages. Otherwise there is no point to keep it in Luci. It's fine to have a check box to allow untrusted packages and/or some warning, but users should have a choice.

[Ansuel]

@XCas13 what about situation when the device doesn't have connection ?

[XCas13]

@XCas13 what about situation when the device doesn't have connection ?

Agree, this case is also real, but imho most often users will be trying to install untrusted packages. I'm not asking about creating a security breach, but about better user experience. You can connect by ssh and run apk add --allow-untrusted anyway. However, it's annoying that you have to do this, instead of having nice and quick way to install packages through Luci.

[Konstantin-Glukhov]

I pushed the change that leave opkg functionality alone. If you decide to add '--allow-untrusted' option, I would happily do this. Just let me know.