[AppStream] Requiring a specific version of something

[Matthias Klumpp]

2016-12-20 15:05 GMT+01:00 Richard Hughes <hughsient at gmail.com>:
> On 20 December 2016 at 13:14, Matthias Klumpp <matthias at tenstral.net> wrote:
>> Dependency logic, the thing we wanted to avoid in AppStream ;-)
>
> Right; but every system seems to get pulled into this for practical
> reasons, e.g. snappy and flatpak also.

Flatpak too? That would mean I was right the whole time with my more
modular approach to bundling, yay ^^ - why doesn't it feel better? :P

>> For bootloaders and firmware: What exactly is the version you require,
>> i.e. *which* bootloader and *which* firmware should the version
>> relation apply to?
>
> Usually these are specific the hardware; sometimes they're actually
> the same image and just booted with a different set of USB
> descriptors. There's not a generalized definition IMHO.

But a firmware can be for many devices, shouldn't we define which
firmware the version comparison should act on? Or does "firmware" mean
"the current installed firmware"?

>> And what is a "validation" exactly?
>
> Ohh, just an example. Some devices have a few different "slots" where
> the slots have to be populated and updated in different ways.
> Validation would just be a combination of images for signing for
> example.

Crazy. I never thought this would be that complex. I think I just need
to blindly trust you on that ^^

>> In any case, we also need to use the same version-comparison algorithm
>> - I just recently had funny results because someone mixed different
>> algorithms comparing versions differently (I would suggest using the
>> RPM version-compare algorithm, which is pretty good - maybe make it
>> handle "~" chars better).
>
> I've got a naive as_utils_vercmp() in appstream-glib; I don't think
> that supports anything other than [<numeric>.]

AppStream/libas is a bit more advanced in that regard:
https://github.com/ximion/appstream/blob/master/src/as-utils.c#L933
(based on what RPM has) - but I always wanted to edit the algorithm
slightly to be less surprising for both DPKG and RPM users.

>> I need to let this sink in and think about this a bit more (I don't
>> want to have fiormware take a very generic name and then make it have
>> a very specific meaning, we e.g. already have this with the
>> <location/> tag which is pretty much used exclusively by firmware).
>
> What about another more generic proposal:
>
> <requires type="application">
>   <id>org.freedesktop.appstream.cli</id>
>   <version>2.0</version>
> </requires>

Aside from type= needing to be "component", this is incredibly
verbose... I don't know though whether that is a good or a bad thing
:P
Will have have a dependency solver in AppStream at some point? I kind
of hope that this won't happen...

> (although I'm not sure we want to support this, it gives us some
> headroom if we ever do)
>
> <requires type="firmware">
>   <id>bootloader</id>
>   <version compare="equal-or-greater">1.0</version>
> </requires>
>
> Also, omitting the compare attribute must mean "exactly the same string", right?

Yes, that would make sense.

Another idea:
<requires type="component">
  <id version="2.0" compare="greater-equal">org.example.Foobar</id>
</requires>

Or
<requires>
  <component version="2.0"
compare="greater-equal">org.gnome.Software</component>
  <firmware version="1.1" compare="lower-equal"/>
</requires>

Hmm...

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