ECM metainfo path

[Harald Sitter]

On Fri, Apr 22, 2016 at 10:13 PM, Matthias Klumpp <matthias at tenstral.net> wrote:
> 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.

I am actually not sure how we handle this for ECM.  CCing Stephen
Kelly who I think is semi-maintaining ECM right now.

The way I see it this could be done by adding a new variable that uses
/metainfo (which probably will look awkward given the current variable
is what we should be using for /metainfo ;)) and make usage of the old
variable raise a bazillion warnings, expecting the individual devs to
transition their apps.

Since that is slightly meh, considering the "wholesale" platform
decision this is, I'd suggest the following:
- _METAINFO points to /metainfo
- add a compile-time switch to ECM which forces _METAINFO back to
/appdata (i.e. opt-in backwards compat on a platform level)
- make sure this change is visibly noted in release changelog
(- _APPDATA gets introduced installing to /appdata in case a dev
explicitly needs to install there for some reason ... this actually
might be folly and superfluous since they could just as well
$DATAROOT/appdata)

The probably best solution would be to have install calls with
_METAINFO install to both /appdata and /metainfo and have a switch
that turns off the /appdata compat, I am guessing that'll be
technically impossible though.

HS