[AppStream] Requiring a specific version of something

[Matthias Klumpp]

2016-12-19 19:47 GMT+01:00 Richard Hughes <hughsient at gmail.com>:
> 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.

Why does the AppStream metadata - which purely describes a software
component - care whether multiple installations are allowed? GS should
query that information from Flatpak-specific data, just like it uses
Flatpak to determine the size of the download and whether the bundle
is installed at all.

>> 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.

Jup, it's pretty much the same  - you convinced me to use the value
tags with a property instead of making real tags to allow arbitrary
strings in there.

>> 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.

No matter whether required or not, it will add complexity and - if
added to metainfo files - will leave upstreams confused what to
include and why, because some SCs might have different inclusion
criteria than others.

>> 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

For that I would rather like to see a new <price/> tag (with
upstream's suggestion on how much this should cost), and the backend
(PackageKit/Flatpak/whatever) should determine whether a Payment is
necessary or optional.

> 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"/>

Price tag, or ask backend.

> <value key="FlatpakMultipleInstallations"/>

Ask Flatpak whether this is allowed.

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

Add extra tag requires_bootload

> </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.

I think the issue here is that I see AppStream as format for purely
metadata and purely for describing software components - and not
adding things which influence the app-behavior or adding keys to
support arbitrary other software which wants to replace its archive
metadata with AppStream.

At time, I do like AppStreams rather small scope, because it gives the
project focus and clearly defines what it is. If we add data replacing
metadata of other systems, so you can use AppStream as replacement for
the RPMDB or Debian's control files or $anything, we make the whole
problem much harder. I am not completely against that, but if we want
to expand the scope of AppStream, we need to do that consciously and
by gradually adding more and more fields to replace metadata which is
supposed to live in other systems by AppStream's current design.

Cheers,
    Matthias

-- 
Debian Developer | Freedesktop-Developer
I welcome VSRE emails. See http://vsre.info/