Skip to content

package-manager: migrate to apk-tools JSON API#8463

Merged
systemcrash merged 1 commit intoopenwrt:masterfrom
Konstantin-Glukhov:package-manager
Apr 9, 2026
Merged

package-manager: migrate to apk-tools JSON API#8463
systemcrash merged 1 commit intoopenwrt:masterfrom
Konstantin-Glukhov:package-manager

Conversation

@Konstantin-Glukhov
Copy link
Copy Markdown
Contributor

@Konstantin-Glukhov Konstantin-Glukhov commented Mar 25, 2026

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: <[email protected]> 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
Copy link
Copy Markdown
Contributor

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
Copy link
Copy Markdown
Contributor

efahl commented Mar 27, 2026

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
Copy link
Copy Markdown
Contributor Author

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
Copy link
Copy Markdown
Contributor

efahl commented Mar 28, 2026

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
Copy link
Copy Markdown
Contributor Author

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
Copy link
Copy Markdown
Contributor

Retain opkg for now, please.

@XCas13
Copy link
Copy Markdown

XCas13 commented Mar 30, 2026

@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
Copy link
Copy Markdown
Contributor

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
Copy link
Copy Markdown
Member

Ansuel commented Mar 30, 2026

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

@systemcrash
Copy link
Copy Markdown
Contributor

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
Copy link
Copy Markdown

XCas13 commented Mar 30, 2026

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
Copy link
Copy Markdown
Member

Ansuel commented Mar 30, 2026

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

@XCas13
Copy link
Copy Markdown

XCas13 commented Mar 30, 2026

@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
Copy link
Copy Markdown
Contributor Author

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.

@systemcrash
Copy link
Copy Markdown
Contributor

@efahl this looks ready - does it line up with your understanding of APK JSON output?

@efahl
Copy link
Copy Markdown
Contributor

efahl commented Apr 8, 2026

The apk query output calls the size of the package file-size, where opkg lists it as Size:, which gets mapped to pkg.size in the js here. I don't see anything that is mapping file-size -> size anywhere.

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.

Signed-off-by: Konstantin Glukhov <[email protected]>
@Konstantin-Glukhov
Copy link
Copy Markdown
Contributor Author

The apk query output calls the size of the package file-size, where opkg lists it as Size:, which gets mapped to pkg.size in the js here. I don't see anything that is mapping file-size -> size anywhere.

Addressed.

@systemcrash
Copy link
Copy Markdown
Contributor

Any final comments @efahl ? If not LGTM and drop the patch in main.

@efahl
Copy link
Copy Markdown
Contributor

efahl commented Apr 9, 2026

Looks good, commit away!

@systemcrash systemcrash merged commit 1624418 into openwrt:master Apr 9, 2026
6 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants