[AppStream] Requiring a specific version of something

[Richard Hughes]

On 19 December 2016 at 12:48, Matthias Klumpp <matthias at tenstral.net> wrote:
> Can you be more specific about the first case? What exactly would be
> the criterium for (not) showing the component?
> (It's clear for the fwupd case, but not for the other one)

>From what I remember (jrocha, help!) it was that the "endless" plugin
in gnome-software didn't know how to install the flatpak application
in a way that it would appear on the front page of the Endless shell.

> I think this is a very bad idea, because it hardcodes assumptions
> about which tool processes the data and requires the metadata author
> to care for them all - which means they would need to set a minimum
> version for GNOME Software, Ubuntu Software (whatever they use on
> Unity8), AppCenter, KDE Discover, appstreamcli, Isenkram, etc. - this
> will explode quickly and is IMHO a very unclean way to solve this
> issue.

Well, I don't disagree. What is happening is that specific vendors are
choosing a software center for their deployment (e.g. gnome-software
for endless) and then adapting the SC work perfectly with the
available metadata on the specific image and hardware that's being
shipped. The LVFS is also targeting fwupd, and although there's
nothing specific about the metadata so far the only promise is that
"git master fwupd" will work with the newest version of fwupd.

> In the worst case we could define a firmware_compat_level integer which would define the
> seupported set of features like we use the SONAME for ABI tracking

We could just dump the idea of version numbers and just have provide
strings... for GNOME Software I could use
org.gnomeSoftware::Plugin::flatpak{multiple-installations-support}.
This also has the advantage that you can backport a feature into an
older branch.

> You may use the <custom/> tag for that:
> <custom>
>    <value key="foo">bar</value>
> </custom>

Ohh, so is <custom> basically what I've been using as <metadata>? If
so I'll update my fallback code.

> In any case, I think by introducing these specific frontend
> dependencies we will shoot ourselves in the foot in the long run, and
> also over-complicate the task of writing metadata.

I think it's a balance between allowing the complicated use case
without making the tags a requirement. i.e. make it possible, but
don't make it a requirement.

> While I do get the point for this for fwupd (and I think we can find a
> better solution for this specific case), I don't get why this is
> relevant for fonts/apps/etc. - can you maybe elaborate on that?

I think all the time software centers value-add things we need this
kind of requirement check. I can really imagine something like
GnomeSoftware::AllowsPurchasing so we can hide only-purchasable apps
when either the UI isn't present in the code or if the user has
explicitly disabled it.

What about an amended proposal of:

<requires>
<value key="AllowsPurchasing"/>
<value key="FlatpakMultipleInstallations"/>
<value key="PluginUnifyingNordic"/>
<value key="PluginUnifyingTexas"/>
<value key="BootloaderVersion" type="version-least">0.1.0</value>
</requires>

I guess some things would be standard between implementations, perhaps
the BootloaderVersion thing and AllowsPurchasing but this would be a
PITA to standardize, worse than kudos IMHO. For some things there
might be quite specific quirks we need, like
PluginUnifyingCanSwitchBootloaderMode.

Richard.