[AppStream] Adding another component specifier for variant

[Matthias Klumpp]

Am Di., 24. Sept. 2019 um 14:35 Uhr schrieb Richard Hughes
<hughsient at gmail.com>:
>
> 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.

Maybe "self" or "this" would have worked as well?
Is there ever a case that this restriction is applied on a per-release
basis, so that firmware isn't actually updated to a newer version
after a certain point? (I hope not, that feels like a flaw, but yet I
still wonder...)

FWIW, since this is implemented and working and I see no reason at all
for change (in fact, it's odd that "firmware" isn't permitted in a
"requires2 tag yet), I may just add this to the AppStream spec as it
is.
Then the LVFS metainfo files should validate fine and be 100%
AppStream compliant (minus the artufacts stuff, but adding that in a
backwards-compatible way would be fun).

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

That's the separate competing proposal ^^ (and the one I slightly prefer)

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

I probably don't mind it because the German word is exactly the same,
only capitalized ^^

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

I thought about that, and name_variant seems to imply it's another
variant of the <name/> tag, i.e. an alternative name.
<name_variant_suffix/> would be absolutely clear for everyone, showing
that it's used with the name, that it denotes the variant of the
component and that it's a suffix to the name.
It may just be a bit long though ^^
"Appendix" is something I read as supplementary material, postfix
feels a bit... "mathematical" but would work as well. Suffix is just
shorter.

Cheers,
    Matthias

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