Limiting what is in the appstream

Alexander Larsson alexl at redhat.com
Wed Oct 5 14:25:25 UTC 2016


I have gotten requests from Endless about having a way to limit what is
in the appstream branch, because they want to store all the apps in a
single repo, but some apps are targeting an older OS version, and some
a newer, and you only want to see the newer ones. Is that correct?

Additionally, my recent research into flathub versioning seems to imply
that we want the per-app flathub repos to have branches for all
historical "stable releases" (so, in gnome terms, we would have "3.18",
"3.20", "3.22", "stable" (pointing to 3.22 atm) and "master" (nightly
build). However, in the UI we probably don't want to show things that
are "old enough". So, the flathub user could configure with branches
get put into the appstream.

So, I was thinking of adding some configuration to the repo (in the
config file, similar to the currently stored repo title) which lets you
specify a set of globs for the branches to be added to the appstream
branch when we run build-update.

However, I'm not sure how e.g. gnome-software would handle this? What
happens if there is some flatpak ref in the repo that doesn't have a
corresponding appstream node?

Additionally, how would endless actually use this for an older version
of the OS, if only the latest versions have appstream data? Maybe
instead of just filtering out stuff we should let you create
"collections" which would generate separate appstream branches. The
latest versions would go in the default appstream branch, but then we
could create an appstream/version_0.9 branch, and let the client side
decide what collection to mirror from a repo.

Does that make sense?






More information about the xdg-app mailing list