[AppStream] RFC: A UniqueID in AppStream

[Matthias Klumpp]

2016-08-10 18:26 GMT+02:00 Richard Hughes <hughsient at gmail.com>:
> On 9 August 2016 at 17:33, Matthias Klumpp <matthias at tenstral.net> wrote:
>> For what do you need that exactly?
>
> So, I've got reservations about dropping the "type" of component for
> several reasons:
>
>  * Are we sure there is no ID overlap between addons, apps and firmware?

Yes. The spec requires this, and I am taking this requirement really
really serious. The asgen tool building the data for Debian is
checking for uniqueness and will exclude software if there are ID
collisions (I will even refine that logic a bit for the next release).
I also hope that any other "app store" shipping metadata will enforce
the same uniqueness rules.

>  * Sometimes we want to treat the component differently depending on
> the type, for instance not requiring descriptions for addons, or
> allowing release links in firmware components.

For that, they already have, well, a type ;-) Just read their type
property in the XML/YAML, or, well, run get_kind() on the actual
component to get the enum...

> [...]
>>> I think you've convinced me, actually :) I've dropped arch and version
>>> from the API.
>>
>> \o/
>
> Well, there's no point me asking for comments if I'm not going to take advice :)

Sure - also, especially for spec changes, one sometimes lives in one's
own world and thinks something is a good idea, while it actually is
not. So it's incredibly useful to run it by other people to improve
the result before it is in the spec for almost eternity. But you know
that, we are playing this game for a while with IMHO great success :-)

>> The "Merge rules" are really terrible at time, which is something I
>> wanted to discuss anyway: Do we ever want to have a merge component
>> *deleting* data from existing metadata? Should, for list types like
>> <categories/>, the merge component extend those or replace those?
>
> So, I don't think "merge" is a type; it's a policy on what to do on
> conflict. I think that <component merge="replace"> and <component
> merge="append"> is much more flexible, and doesn't mean we have to
> overload the type parameter with a virtual type that just encodes
> merge policy.

Right... This actually does make quite a lot of sense to me. It's not
too late to change the spec and implementation on this...
We still need some kind of rules, e.g. what to do with translations if
the untranslated property is overridden, but that will be much easier
to write.

And we can get rid of the pseudo-component type, which isn't that great.

Cheers,
    Matthias

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