main: pass --allow-custom to compose

[davidmhewitt]

Add a CLI option to forward --allow-custom to appstreamcli compose. Store the setting in BuilderContext and plumb it through manifest cleanup.

Since ximion/appstream@4d7bd4a the --alow-custom arg has been used to allow certain <custom> key-value pairs to make it through the compose process into the final metadata. By default, this value is set to none allowed.

In elementary AppCenter, we use custom metadata for things like allowing developers to set a suggested price for their app:

  <custom>
     <value key="x-appcenter-suggested-price">3</value>
  </custom>

Because we have no control over the --allow-custom arg during the flatpak-builder appstream compose, these tags are getting stripped from the final metdata. So, proposing adding this argument to allow controlling this in a flatpak-builder run.

[bbhtt]

We (Flathub) have been patching Appstream for this since the last 3 years. See flathub-infra/appstream@bc04a40

I really don't like that with the CLI arg we have to pick and choose and in my opinion it should be either all custom tags propagated or none. I talked with ximion about this somewhere but iirc it didn't move forward.

I want to support that exact behaviour ie. propagating all custom tags, when I complete the port to use the API in #664.

[bbhtt]

Btw, if you are already using flatpak-github-actions, the official image to use with it is, https://github.com/flathub-infra/actions-images which already has that patched AppStream.

[davidmhewitt]

in my opinion it should be either all custom tags propagated or none

There's one case where it's useful to have a configurable subset.

For example, a software store (Appcenter) might choose to filter the tags to include only the Appcenter supported tags.

It would allow the app developers to put a bunch of tags for different stores/purposes, and then the stores themselves decide which ones to keep.

But yeah, I guess it only offers a bit of a size saving and having unsupported tags there (if we transfer all of them) isn't really an issue.

Probably the issue appeared on our side after switching docker image or something.

[bbhtt]

Child tags inside the custom tag are free form, and if someone is parsing them they are supposed to filter it on their end and read the tags they support. The problem with not passing everything is an either an app developer distributing on multiple stores have to build it differently for each one or the store's build service will keep needing to change the arg values as downstreams grow.

Flathub uses around 6 custom child tags, I know COSMIC uses some different ones too for their appstore client etc.

Flathub's central appstream catalogue is parsed by multiple downstreams store clients etc. who want will want their tags to show up eg. for recommendation banners, classifications etc. This is mostly going to be the same for anyone hosting a Flatpak app store and having downstream consumers of it.

The most stable, long term option is letting everything go through and let downstream consumers decide which ones they need. I don't want to add an arg then walk back on it in the next release.

[davidmhewitt]

Sure, understood, thanks!