[AppStream] Adding another component specifier for variant

[Matthias Klumpp]

Am Mo., 23. Sept. 2019 um 14:51 Uhr schrieb Richard Hughes
<hughsient at gmail.com>:
>
> On Mon, 23 Sep 2019 at 13:36, Matthias Klumpp <matthias at tenstral.net> wrote:
> > 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.
>
> There are no such things as dumb questions, only lack of documentation :)

Hehe ^^ - There might have been documentation here that I didn't find ^^

> > 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"?
>
> Good question. The <name> isn't translated by the vendor, ever. It's
> typically a trademark and designed to be the same in all languages and
> locales. We do want the "System Update" bit translated tho, and this
> is why we do the client-side appending. We also don't want the
> category in all cases, e.g. if we're showing a list of hardware we
> don't want a hundred "System Update" words at all, we just need the
> device name.

Yikes... That sounds really hackish, but at the moment I also can't
think of anything better that would be functionally equivalent. So,
it's probably fine ^^
When I hear "System Update", I immediately think it's an OS update,
not that firmware is updated (even though the operating system and
hardware system are both "systems" in a way). Was the name chosen
because the non-tech user doesn't know what "firmware" is, or does
this have some deeper roots?

> > Why is the GUID in a <provides/> tag? (and why type of provided item
> > is this? modalias?)
>
> It's a GUID, e.g.
>
>   <provides>
>     <!-- USB\VID_17EF&PID_3083 -->
>     <firmware type="flashed">d66bf84b-c3ba-508c-bc55-0d445413d3d4</firmware>
>   </provides>

Right, that makes complete sense! I briefly forgot how the firmware
provides type worked and that it handles the hardware dependency
already. Man, the AppStream spec has gotten quite extensive over the
years!

> > 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?
>
> Yes, we use <requires> if we need a specific fwupd version, for instance:
>
>   <requires>
>     <id compare="ge" version="1.3.2">org.freedesktop.fwupd</id>
>   </requires>
>
> > So, there are two components here, that provide/require different
> > GUIDs dependent on which model variant the firmware is for, right?
>
> Yes.
>
> >In that case, why is the <name/> field identical for those?
>
> A good question. I think the idea is that we only show the "variant"
> if there are multiple components with the same visual name, so we
> wouldn't have:
>
> * ThinkPad X1 (US)
> * ThinkPad P70 (US)
> * ThinkPad P50 (US)
> * ThinkPad P51 (US)
> * ThinkPad P51 (China)
> * ThinkPad P51 (US)

I think this may actually be a good definition for a potential
"variant" or "flavor" or whatever it is named tag.

> > Also, they
> > surely must have different component-ids, if they actually are
> > multiple components...
>
> Yes, the component IDs are different with the different variants.

Phew, I am very relieved :-D
I guess the case when Flatpak occasionally renamed IDs and they
couldn't be matched to what distros shipped anymore got me quite
worried about the ID integrity now ^^

> > What's a branch? That doesn't exist in AppStream...
>
> Hmm, that might be a flatpak thing; forget I mentioned it :)

If it's a Flatpak-specific extension, I may need to look into that. My
plan is to have all 3rd-party extensions to AppStream either
integrated into the spec, their usecase covered by a possibly
different mechanism, or explicutly rejected before I release AS 1.0.
A "branch" sounds like a software delivery method thing, like a
deployment channel, so that's either out of scope for AppStream or may
belong into a <release/> tag.

> > Having variants with the same ID kind of defeats that, but maybe I am
> > also just not getting the point here yet.
>
> A different ID is used at the moment.

Yay!

So, I think I do understand the problem now, and I guess we can cover
this. Not sure if a "variant" toplevel tag is the best name, and how
this should actually be specified. I assume the "if there are multiple
components with the same name, the variant string should be appended
to the component's name in round brackets" may be the besr definition.
Maybe a tag name like "flavor" would make sense here, like Linux
distributions have a "KDE Plasma" and "GNOME" flavor. Unfortunately
using that in "operating-system" components wouldn't help displaying
it unless we make additional rules like "show flavor X if desktop Y is
running" rules, which seems overly complicated.
So, possibly keeping it simple and using the narrow definition from
above and accepting that this isn't a commonly used, but still useful
feature may be the right solution.

Let me think about this a bit more - I am certain though that we can
make this work, somehow.

Cheers,
    Matthias

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