I'm opening this mostly as a request for discussion and/or advice rather than a 100% confirmed feature request.

In elementary AppCenter, we obviously use AppStream and semi-recently we added support for managing Flatpak applications alongside the applications managed by PackageKit.

In doing this, we found it easiest to build two AppStream pools, one by default pointing at the DEP-11 data, and another pointing at a pre-processed set of the Flatpak appstream data. This was done so we could clearly tell in code which components had come from which "backend" and we knew if we wanted to install/update/remove a particular component, it was already associated with either Flatpak or PackageKit.

Now, this brings around some issues with searching and sorting as obviously we have to run a given search twice across both pools and then combine the results somehow. I understand that the results that come back from AppStream are already sorted in a kind of relevance order. But without these relevance metrics accessible to us, we can't combine the search results from the two pools in a meaningful way, at least not without implementing a (probably inefficient) relevancy algorithm of our own.

Do you have any opinions on whether these relevancy metrics should be exposed publically, or indeed whether they'd be any use as a comparison between two pools? I guess if those metrics are somehow based on the relative relevancy between components in the pool, then they're not that useful to compare two different pools. However, if an identical component in two different pools always returned the same relevancy for a given search term, then that's probably a useful metric to have?

If you don't feel exposing this is the correct solution, can you think of any way we might combine both of these pools into one while still having a generic way to figure out where a component came from so we can associate it with a backend. I appreciate there's as_component_get_origin, but considering it can be set to anything, it doesn't feel like a fool proof enough way of doing this.

As an aside, from a quick glance, it looks like gnome-software doesn't use the built-in appstream search functionality and instead implements its own on top of libxmlb , again having the AppStream data from different backends in different "silos".