pool: Offer API to look up by bundles

[aleixpol]

It's often that we will need to look up packages by their name. Include some API that helps us do it.

WIP because it would be necessary to look up by e.g. org.kde.dolphin too, not just org.kde.dolphin/x86_64/master. Some idea on how to do this would be useful.

Context for this change is here:
https://invent.kde.org/plasma/discover/-/merge_requests/455

[ximion]

WIP because it would be necessary to look up by e.g. org.kde.dolphin too, not just org.kde.dolphin/x86_64/master.

So, you want an API like GPtrArray* as_pool_get_components_by_cid_and_bundle_id (AsPool *pool, const gchar *cid, AsBundleKind kind), called like as_pool_get_components_by_cid_and_bundle_id (pool, "org.kde.dolphin", AS_BUNDLE_KIND_FLATPAK)? (which would return all components with the given component-ID that also have a Flatpak bundle of any kind associated with them).

Or do you want an API like the one in this PR that just takes org.kde.dolphin/*/* as bundle-ID and fuzzy-matches that?

[ximion]

FYI, there will be a new AppStream release this Thursday, in case you do want to get this change in by then.

[aleixpol]

No, I do not want the component id, just the bundle id. In fact, part of the problem is that sometimes we know the flatpak bundle id but not the component id.

Or do you want an API like the one in this PR that just takes org.kde.dolphin// as bundle-ID and fuzzy-matches that?

That. Which is what this wants to do.

[ximion]

Okay :-)
Do you think you'd ever want some "fuzzy matching" for bundle IDs? (I don't think so, but just in case, so we don't need to adjust public API again later).

Also, a bunch of comments on the code ;-)

[ximion]

this needs a GIR wrapper, like the one below too... But I could add that as a follow-up commit, if you don't want to dive into writing binding code.

[aleixpol]

Please, I'd appreciate it if you could look into this later.

[ximion]

It's quite trivial, so, no problem :-)

[aleixpol]

Do you think you'd ever want some "fuzzy matching" for bundle IDs? (I don't think so, but just in case, so we don't need to adjust public API again later).

I can see the use-case for wanting to match org.kde.dolphin/* and org.kde.dolphin/x86_64/master and even org.kde.dolphin/*/master.

I don't think we need more flexibility than that, but considering here we are supporting different formats from flatpak, I'm not sure we can come up with a simple API to cover this other than the wildcards.

[ximion]

The problem is that I don't think libxmlb supports wildcards to match text strings... It can fuzzy-match strings as described in https://github.com/hughsie/libxmlb/blob/567d261706add40cbe6a5acbd2a3f504b80449de/src/xb-string.c#L141-L147, but doesn't have support for wildcards for node text content.

I think the best we could do, and which might probably even work here, is do an optional prefix match instead of an absolute match (so the input would be org.kde.dolphin/ and it would match every bundle that has an ID that starts with that string.