[AppStream] Adding another component specifier for variant

[Richard Hughes]

On Tue, 24 Sep 2019 at 13:22, Matthias Klumpp <matthias at tenstral.net> wrote:
> This is a fully valid metainfo file - with one exception:
> The <requires/> tag has a firmware requirement, which the
> specification currently doesn't permit:
> <firmware compare="ge" version="0.1.2"/>
> <firmware compare="ge" version="0.3.4">bootloader</firmware>
> What does it mean if there is a firmware requirement tag with no value?

"itself" -- i.e. the thing we're installing. The example her would be
the requirement is we can only go from >=0.1.2 to the version in the
release, and if we were on some old pre-release 0.0.1 version the
update wouldn't be allowed. I think <firmware compare="ge"
version="0.1.2">firmware</firmware> would look very odd.

> Technically, a "software variant" or "component variant" makes sense.
> The reason why I am unusre about it is that I have a proposal for a
> "variant" component property around that would specify the type of
> e.g. an addon, so you would have `<component type="addon"
> variant="visual"/>` or `<component type="addon"
> variant="functional"/>` to separate between themes and functional
> extensions. That idea isn't fully fleshed out yet (that's why I
> haven't made an "official" attempt yet to add this feature), so we
> should probably just ignore it.

They sound like different types to me, FWIW. An addon is something
that adds to the app with e.g. a new feature, not something that
changes the behaviour or theme of an app IMHO.

> Other words that come to mind are:
> > <alternative>
>
> Firefox is an alternative to Chrome, but yet they are completely
> different products, so I think that's no a good choice.

Right.

> I think either variety or subdividion make sense. When looking at
> dictionaries and a thesaurus, it looks like "variety" isn't actually
> what should be used here and "variant" is the actual noun that
> describes variety as something diverging from the norm.

Agree.

> A "subdivision" implies some form of organizational structure to me,
> which is also not what we actually want to say here.

Agree.

> I could throw "specialization" in the ring, as "China" is a
> specialization of the generic firmware to work in a particular country
> or with a particular device model.

Another example I had today was this:

ThinkPad Thunderbolt 3 Workstation Dock (Audio)

i.e. there are *possibly* multiple sub-components to the Dock, and we
ought to specify which one we're referring to if there is more than
on. At the moment (Audio) is just appended in the <name> but probably
ought to be covered by the same thing.

> Another option the thesaurus suggested as fitting what we mean well
> would be "variation" - that is almost the same thing as a "variant" if
> we want to save that word for later use.

variation works quite well, although my en_GB brain doesn't like the
form. It's quite an uncommon word too.

> What do you think about the last two suggestions? Tbh, I am quite a
> bit more inclined to just use "variant" - while it sucks a bit to use
> such a useful generic tag name, it isn't actually used in AppStream
> yet, there is a useful proposal on the table to make use of it right
> now and the term "variant" would clearly fit the intended purpose of
> the tag very well, which is the most important thing.

Agree.

> What do you think? Sorry for the braindump-style of this mail. This
> happens when I don't have a very clear preference apparently.

What about flipping it around -- <name_variant> makes it clear it's
going to be used with <name>. The other options then become
<name_suffix> or <name_appendix> or <name_postfix>.

Richard.