ECM metainfo path

[Stephen Kelly]

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

Hi,

Thanks for the heads-up.

I'm afraid I'm way out of the loop. I don't know what appstream or /metainfo 
are. However, let's see if I can contribute.

> 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.

>From a few minutes reading about appstream and /metainfo, it seems that 
distros expect certain things to be in /metainfo. Are they still going to 
look for things in /appdata? If not, then we need to try to ensure that we 
install things in /metadata, right? And using the (already aptly named) 
variable for that seems sensible.

Also, I'm not in favor of adding more variables which are hard to remove 
later, especially if they are hard to remove, or as you propose below, are 
designed to have a 'short' life in use. I already don't understand the 
KDEInstallDirs.cmake file, and it's not consistent in some ways which I find 
makes the whole thing hard to maintain and understand (eg see

 http://thread.gmane.org/gmane.comp.kde.devel.buildsystem/9130/focus=9183

)

> 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)

There is an existing variable for this, right? 

KDE_INSTALL_METAINFODIR.

A user needing that to be /appdata can just set it to be that, right? No new 
variable needed?

Otherwise I'm missing something here.

> - make sure this change is visibly noted in release changelog

If I'm right about the above, a note in the changelog for people affected 
sounds like a fine idea.

Thanks,

Steve.