[AppStream] Dependencies on things in AppStream

Matthias Klumpp matthias at tenstral.net
Tue Mar 27 12:26:01 UTC 2018


2018-03-26 21:08 GMT+02:00 Richard Hughes <hughsient at gmail.com>:
> On 26 March 2018 at 19:12, Matthias Klumpp <matthias at tenstral.net> wrote:
>> 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.
>
> For the phones case I can see Mb being a better unit, sure.

I will try to come up with some wording in the specification,
describing a minimal amount of stuff for the requires/recommends tags
and commit that to AppStream.
Before releasing it though, I'll have you take a look at the changes
made, so we can see if that works for us.

>> 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.
>
> Is as a dependency? Dependencies are a two way thing, with all the
> legacy stuff people thinks of as a "dep" -- in as-glib I went for
> AsRequire -- i.e. things the component requires.

Since I also want AsRecommend in that case, to reflect that a thing is
only recommended, not required, but AsRecommend would have the exact
same logic as AsRequire, I thought to just avoid that duplication by
using some generic name.
A requirement as well as a recommendation are a declaration of some
kind of dependency relation between two modules, so that makes sense
to me.

>> Is this some kind of workaround for weird firmware vendors?
>
> Yes and yes.

I am still wondering how to deal with quirks like this one - I would
like to support that stuff in libappstream for convenience, but at the
same time I would really like to not encourage people to use it. The
best way to do that is to not implement an antifeature. Another way
would be to implement, but not document it, but that would be slightly
evil.


More information about the AppStream mailing list