[AppStream] Requiring a specific version of something

[Matthias Klumpp]

2016-12-19 9:57 GMT+01:00 Richard Hughes <hughsient at gmail.com>:
> Hi all,
>
> Twice now I've been asked to be able to ignore an appstream entry on
> condition of some kind of client check. The first request was to be
> able to say "only show this entry in gnome-software > 3.23.1" as the
> code that was able to handle the application was only added in that
> version so earlier versions would fail to install the app. The other
> request is for fwupd where we want to only show the device update IF
> fwupd is new enough that it can support the newer version of the
> flashing protocol AND the bootloader version of the device is of a
> specific version range that can be updated.

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)

> I don't think we want the full dependencies thing (requires, suggests,
> depends etc) but I do think it makes sense to be able to require the
> minimum and maximum versions of the front end tools processing
> AppStream metadata. I think these are segmented by class, so if you're
> processing the metadata with a different software center you'd just
> ignore the metadata item.
>
> Now, the simplest and quickest way to fix these two use cases would be to do:
>
>   <metadata>
>     <value key="Requires(gnome-software:project:version_min)">3.23.1</value>
>     <value key="Requires(gnome-software:plugin:flatpak)">3.23.1</value>
>   </metadata>
> [...]

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.

Is there any way we can have the software center auto-detect whether
it can handle the component? For bundles this should be possible, for
the fwupd case as it is relatively complex, exhibiting more
information about the firmware would make sense. 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
(Debian has something similar when building packages, to enforce old
behavior with newer tools if desired, and to switch to new behavior of
the tools by changing the compat level)

> ..but it's Christmas and I don't want to upset ximion. :) Another way
> of doing this would be:
>
> <x-requires key="fwupd/project/version_min">0.8.0</x-requires>
> [...]

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

I kind of put reality before spec-purity here and the custom tag can
be used to define arbitrary extra values in AppStream metadata and
have them propagate through to frontends (Elementary wanting to use
this for some app-purchasing experiments and me wanting to use it for
some generate-.desktop-file-from-metainfo experiments certainly
helped).

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.

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?

Cheers,
    Matthias

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