📦 Fast Binary Packages from the APK Index

The Qt post mentioned that [yoe] pulls packages from Alpine and presents the prebuilt binaries as virtual units. A new video digs into how that works now, because the mechanism recently changed in a way that's worth explaining: instead of generating a file per package up front, [yoe] reads Alpine's package index directly and builds units on demand.

The old way: a file per package

The previous approach was to keep an alpine/units folder full of autogenerated files, each one wrapping a single Alpine package. main had over 2,000 of them. Scripts generated and updated the set. The community repo was handled more lazily — it has over 10,000 packages, and generating a wrapper file for every one wasn't worth it, so those were generated only as needed.

This worked. But it meant carrying thousands of generated artifacts in the module and keeping them in sync with upstream.

Parse the index instead

Alpine already ships an APK index that contains exactly the information those wrapper files were duplicating — each package's metadata and its dependencies. So the question became: why generate the files at all? Parse the index, and construct a virtual unit for any Alpine package directly from it.

That's the change. The Alpine module now carries just a handful of files — the APK indexes themselves. main is about 2.2 MB per architecture and lists roughly 5,000 packages; community is about 8.7 MB and lists nearly 20,000. The index is dense but simple: a flat list of packages, what each one is, and what it depends on. Everything needed to construct a unit is already in there, so there's nothing to generate and keep in sync.

Only what an image needs

There's one more wrinkle that keeps this fast. Alpine offers around 25,000 packages across both feeds, but [yoe] shows only a few hundred units — in the demo, 363. It doesn't materialize a unit for every package in the index. On startup it scans all the images, walks their dependencies recursively, and generates virtual units only for the packages those images actually reference.

Adding a package is then just adding its name to an image. [yoe] notices the reference, wraps the package, signs it with its key, and serves it from the [yoe] feed automatically. You get access to the entire distribution without paying to enumerate it.

Why it matters

This is the difference between a tool that knows about 25,000 packages and one that drags 25,000 packages around. The app starts fast and stays responsive because it holds exactly the information that images need and nothing more. The full Alpine catalog is one image edit away, but it costs nothing until you reach for it.

What's next

Possibly Debian as an additional package source alongside Alpine. The Videos page has the full walkthrough set. If you've got thoughts on how [yoe] consumes packages, open a discussion or send a note.