ECM metainfo path

[Matthias Klumpp]

2016-04-22 12:45 GMT+02:00 Harald Sitter <sitter at kde.org>:
> Lost mailing list CC, I am assuming that was intentional? (:

Oops, no - I didn't see the CC and didn't hit reply-all then...
Adding the list back (hope your reply isn't private ;-) ), the mail I
sent first is below.

> On Thu, Apr 21, 2016 at 4:21 PM, Matthias Klumpp <matthias at tenstral.net> wrote:
>> 2016-04-21 12:26 GMT+02:00 Harald Sitter <sitter at kde.org>:
>>> ahoy ahoy!
>>>
>>> http://commits.kde.org/extra-cmake-modules/4b7a90bfe7a3e2eb3ae83c946c182a79fabc51e3
>>>
>>> doesn't that break compatibility with older appstreams for everything
>>> that uses ECM? if so, I am not sure that is appropriate TBH
>>
>> It shouldn't, since all tools which handle this have been adapted
>> already - I expect this to be only enabled for the next generation of
>> KDE apps, so this change shouldn't hit distributions right now (I hope
>> I got e-c-m's release schedule right here...).
>
> ECM gets released monthly, so this would hit anyone that wishes to
> push the new ECM onto an existing stack that has an older appstream.

Hmm, that could indeed be a problem. The main component which should
not be out of date is the server-side module which generates the
distro metadata. AFAIK all distros are up-to-date on that, but we
could also wait a few more months to be sure everyone has updated.
The client tools not being updated shouldn't be a big issue, they
rarely read /usr/share/appdata or /usr/share/metainfo.

> And technically we expect distributions to do that which is why we
> technically aren't breaking backwards compat.

Hehe, does Debian know that? ;-)

> Now if you were to say
> that the appstream tools already looked in /metainfo as well as
> /appdata for a year or two

True for AppStream itself (~6months), but the GNOME world switched
only recently.

> but we are simply late to the party, then I
> guess the change might be done just as well even if technically
> breaking compat.
>
> Whether or not we are aware of an ECM user that would have a problem
> with this or not doesn't really factor into it though, just like we
> don't break ABI because we think that no one is using a specific
> interface.

Okay, that's an entirely different thing then - so, when are we
allowed to do such breaking changes?
Moving away from appdata/ is something I care much about, because as
the recent discussion at KDE has shown, people still seem to think
this metadata is only for applications (which it isn't).

I think to not break assumptions, reverting that commit is fine now,
but knowing some time when changing it is okay would also be good.
Generally, the critical factor is distributions upgrading their
AppStream generator, which happened at Debian and Ubuntu, should be
done at Fedora (I need to ask again). I have no data on OpenSUSE and
Arch yet, but I can ask them too.

Cheers,
    Matthias

2016-04-21 12:26 GMT+02:00 Harald Sitter <sitter at kde.org>:
> ahoy ahoy!
>
> http://commits.kde.org/extra-cmake-modules/4b7a90bfe7a3e2eb3ae83c946c182a79fabc51e3
>
> doesn't that break compatibility with older appstreams for everything
> that uses ECM? if so, I am not sure that is appropriate TBH

It shouldn't, since all tools which handle this have been adapted
already - I expect this to be only enabled for the next generation of
KDE apps, so this change shouldn't hit distributions right now (I hope
I got e-c-m's release schedule right here...).
This might be an issue with backports on Fedora, but that would be the
only problem I am aware of. Ubuntu/Debian are fine, and AppStream,
libappstream-qt, libappstream, appstream-glib appstream-builder and
appstream-generator are all adapted for this change.

So it should be safe ^^
Honestly, I am very eager to get rid of the old misleading name too -
if you notice anything that breaks, please let me know and we can
revert that change.
(One thing required in particular would be updating the validator at
the CI system (which would only validate the new path then, though))
Cheers,
    Matthias


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