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. _______________________________________________ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
