[AppStream] Dependencies on things in AppStream

[Matthias Klumpp]

2018-03-26 10:21 GMT+02:00 Richard Hughes <hughsient at gmail.com>:
> On 25 March 2018 at 22:16, Matthias Klumpp <matthias at tenstral.net> wrote:
>>> Eww. Can we not just make this an integer number of bytes/Mb/Gb? The
>>> number of GB seems like it has the required precision.
>> Maybe using MB as the default precision is best here, to get some
>> compromise between precision and readability (while we we will likely
>> only see GB-sized values here, there might be other applications where
>> using MB makes more sense (GPU-memory?), and using a different unit
>> there would be confusing).
>
> Are there games that work okay with 1.5Gb of GPU memory and not 1Gb? I
> really think GB should be the minimum going forward. I assume the
> value here is going to be "what you have installed" rather than "what
> you have available now" otherwise it's going to be relaly confusing
> when apps "work" one day, and then refuse to "work" another day.
> Machines also don't come in multiples of Mb anymore, the realistically
> smallest machine you can find running Linux these days has 1Gb of
> memory.

We would certainly not use the "currently free RAM space" as metric,
that would be absolutely mad (in that case we might also add a "clock"
requirement that only allows installing the app on every even hour).
The reason for using MB would be that I think for smaller systems it
would make sense to define "needs 1.5GB of space" (like phones, for
example), and that I would like to use the same unit size for the
"needs at least X amount of free space"[1] requirement, where MB would
make sense too, I think.

>> I actually like your approach a bit better though, it's more flexible
>> and easier to parse.
>
> Thanks :) it also means I don't need to change the XML format or any
> of my code ;)

I haven't looked at what appstream-glib does, but at the moment in my
mind I imagine a single AsDependency class with types similar to
Asprovided and an importance property of REQUIRED or RECOMMENDED.
As for the compare and version XML attributes, I really see no
drawbacks. Declaring dependencies in XML is annoying, and this
approach is both readable and can be parsed quickly.

>> I didn't think of allowing regex matching (eww!!!) but if that's
>> something firmware regularly wants, we could add it as well.
>
> Well, I didn't originally have it either. Glob (as in fnmatch) is
> super useful, but to avoid AND, OR, SUFFIX and PREFIX operations
> regex's are really much easier to explain.

Is this some kind of workaround for weird firmware vendors? Because it
means if the regex accidentally matches, software will get downgraded,
which is not what you actually want most of the time.

>> The issue of "my software can use $range_of_hardware, either of which
>> is okay" will come up though, and people will want and and or
>> relations sooner or later.
>
> I think we tell them to KISS. I think any time we allow application
> authors to do something complicated a significant minority will get it
> wrong.
>
>> That means we will end up with some kind of
>> "org.freedesktop.generic_component.SQLDatabase" pseudo-ID at some
>> point though.
>
> Apps typically don't need an "SQL database" they need an explicit
> runtime dep, e.g. mysql or sqlite. I don't think you want all the
> logic from the Debian control file in AppStream at all.

With feature requests like
https://github.com/ximion/appstream/issues/67, I guess having that
logic makes sense though, to make a particular theme dependent on a
range of different GTK+ versions, for example.
There is also feature request
https://github.com/ximion/appstream/issues/157 which could also be
addressed with a more expressive dependency system.

For the case of Debian, I guess I will have a flag for
appstream-generator to strip out all dependencies on interfaces & Co.
in case the component is backed by a package. But in case the software
is shipped by other means, this information can be very useful.

[1]: For that particular "needs space" requirement, we need to figure
out what it actually means before I add it in its final form. Space on
the install target disk? Space on any arbitrary connected storage
medium? Also, for the size of the installed app only, having a
dedicated and precise install_size tag might actually be more useful.
(Initially, I plan to add just a very small amount of dependency types
to the spec, and we can expand on that later)