On Fri, Apr 22, 2016 at 10:13 PM, Matthias Klumpp <matth...@tenstral.net> wrote: > 2016-04-22 12:45 GMT+02:00 Harald Sitter <sit...@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 <matth...@tenstral.net> >> wrote: >>> 2016-04-21 12:26 GMT+02:00 Harald Sitter <sit...@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 _______________________________________________ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
