[AppStream] Adding another component specifier for variant

Matthias Klumpp matthias at tenstral.net
Mon Sep 23 12:36:22 UTC 2019


Hi!

Am Fr., 20. Sept. 2019 um 10:13 Uhr schrieb Richard Hughes
<hughsient at gmail.com>:
>
> Hi all,
>
> At the moment the LVFS and fwupd are using AppStream to describe the
> firmware. On the most part it's going pretty well, but I'm again
> asking for another tag to fix this bug:
> https://github.com/fwupd/lvfs-website/issues/373 -- which is now being
> requested by Lenovo and Dell.
>
> So far we use the model name (e.g. ThinkPad P50) in the <name>, a
> category of  "X-SystemUpdate" and the developer name to turn this into
> "Lenovo ThinkPad P50 System Update" in the GUI which is fine for 99%
> of cases.

Okay. I don't think I fully understand the problem, so let me ask a
few possibly dumb questions in order to understand the whole process a
bit better.
Why is there a category "X-SystemUpdate" for this? Why isn't "Lenovo
ThinkPad P50 System Update" the component name and the component of
type="firmware"?

> In the 1% there can be more than one "variant" of the laptop
> model, for instance one version for the US market and one version for
> the China market, or a limited version with some kind of speciality
> like being designed with some extra security features. Although those
> systems have different GUID <provides>

Why is the GUID in a <provides/> tag? (and why type of provided item
is this? modalias?) If the firmware update requires a certain system
with a specific GUID, this should be mentioned in a <requires/> or
possibly <recommends/> tag, shouldn't it?

> they still look like
> "duplicates" visually in the LVFS as they have the same composite
> title.

So, there are two components here, that provide/require different
GUIDs dependent on which model variant the firmware is for, right? In
that case, why is the <name/> field identical for those? Also, they
surely must have different component-ids, if they actually are
multiple components...
If there is one component providing both GUIDs for some reason, why is
that? Also in that case, why does this show up multiple times in LVFS?

> What I was going to suggest was an optional <variant> translatable tag
> that can describe the component where the name itself is not suitable.
> I did think about (ab)using the <branch> for this,

What's a branch? That doesn't exist in AppStream...

> but that feels icky
> and isn't marked for translation. This might be useful for other
> software too, for instance a flatpak with the patented stuff ripped
> out (and a different app-id) could be a variant to avoid duplicate
> entries in GNOME Software. Other ideas welcome!

Any such change would still result in a component with the same ID as
before. And one of the central dogmas of AppStream is the guarantee
that if the component-ID is identical, you get the same software.
Having variants with the same ID kind of defeats that, but maybe I am
also just not getting the point here yet.

> The fallback is that I do something like <X-Variant>China</X-Variant>
> or even <metadata><value key="LVFS::ComponentVariant">China</key> but
> both of those feel like the wrong thing to do. Ideas welcome, thanks.

If you use the <custom/> tag for anything, that would work of course,
but that stuff isn't translatable and if we can get AppStream to
fulfill your needs natively that would of course be much better :-)

Cheers,
    Matthias

-- 
I welcome VSRE emails. See http://vsre.info/


More information about the AppStream mailing list