Adding support for Alpine Linux

[Cogitri]

Hello,

I'm currently looking into adding support for Alpine Linux to appstream-genearator so we can ship appstream data in Alpine Linux 3.12 (and as such postmarketOS) since we've recently gotten support for installing packages via GNOME Software. I figured it'd be good to discuss some things before I go ahead and start implementing something.

• I see most other backends parse the repository index manually. I'd rather not parse it manually since we use a custom format for our APKINDEX and I have D bindings for our package manager, apk-tools, anyway. Would it be acceptable to make the apk backend optional and depend on that lib?

• We currently don't embed file lists into our repository index, nor do we embed it in the metadata for our packages. This will hopefully be fixed in the next version of our package manager, but right now the only ways to know what files are in a package are to either peek into the package archive or to query https://pkgs.alpinelinux.org .

[ximion]

Hi!
Sounds nice!

I see most other backends parse the repository index manually. I'd rather not parse it manually since we use a custom format for our APKINDEX and I have D bindings for our package manager, apk-tools, anyway. Would it be acceptable to make the apk backend optional and depend on that lib?

Yes, that would be fine - testing the code via the CI may be a bit difficult though (unless your package manager's bindings are in Debian). Depending on D libraries is often really annoying due to their unstable ABI, that's why this is avoided often.

We currently don't embed file lists into our repository index, nor do we embed it in the metadata for our packages. This will hopefully be fixed in the next version of our package manager, but right now the only ways to know what files are in a package are to either peek into the package archive or to query https://pkgs.alpinelinux.org

I wouldn't make web queries, that sounds like a ŕecipe for very slow code. You do not need file lists for asgen to work. Those re mainly needed if package split their files over multiple packages and we need to hunt down icons archive-wide.
Also, asgen will create its own file lists, simply because it needs to open almost every package anyway. So, all you need to do to make this work is implement the contents() property ( https://github.com/ximion/appstream-generator/blob/master/src/asgen/backends/interfaces.d#L125 ) of the Package interface to return a file list that you created by possibly reading the local tarball of your package manager. That will be slow at first, but asgen caches this stuff aggressively so subsequent runs should be really fast.

Let me know if you have any further questions :-)

[Cogitri]

Thanks for your answer, that helped a lot already! :)

Depending on D libraries is often really annoying due to their unstable ABI, that's why this is avoided often.

Ah, we'd only need the D module files, since we only need the function prototypes, so that wouldn't be a problem.

I think I'm mostly set now, I'm a bit unsure what the suite and section parameters for packagesFor are for.

[ximion]

I think I'm mostly set now, I'm a bit unsure what the suite and section parameters for packagesFor are for.

That's Debian-ish lingo. A "suite" is the highest organizational unit of the archive, a "section" (or actually "component" in the Debian archive, but asgen calls this different here to be less confusing with AppStream components) is a subdivison of a suite.

Suites usually match to releases, for example Debian 10.x (Buster) has a suite "buster" for its packages, and another suite "buster-updates" for updates to the release. Each of these suites is subdivided into the sections "main", "contrib" and "non-free" depending on the free-ness of the shipped software.

Looking at the Alpine package repo (and knowing nothing about Alpine) it looks like the "suite" is what you call "branch" (so, "edge", "3.11", "3.10", ...) and the "section" would be what you call "repository", so "main", "community" or "testing".
Rolling release distros like Arch just set a generic "arch" suite name and just use the sections, as they don't really have a separate repo for any release.

I hope this clarifies things and doesn't make them more confusing ^^

[Cogitri]

I hope this clarifies things and doesn't make them more confusing ^^

It sure did, thanks for the explanation! I've opened a PR, let's move the discussion to that, OK? :)

[ximion]

Ok, I'll close this report then.