After discussing the feature over it became apparent that developers will need to be pro-active at generating the metadata whenever it's needed and that it's not clear that having everything is overall useful.
This change will make the kpackage_install*_package() calls not install an appdata.xml file by default.
CCBUG: 403118
Plasma Workspace doesn't install appdata anymore
| No Linters Available |
| No Unit Test Coverage |
| Buildable 9777 | |
| Build 9795: arc lint + arc unit |
Conceptual +1; giving everything autogenerated yet sparse AppStream data doesn't provide much value and causes various problems with how app store apps (e.g. Discover) present our software. See https://bugs.kde.org/show_bug.cgi?id=403120. AppStream data should ideally be handmade by the developer because the whole point (well, one of them) is that it's for marketing and branding purposes.
LGTM technically. Also looks crazy scary invasive though from a packaging POV :O
What if a third party user of kpackage actively relied on the appstream data being auto-generated? Wouldn't this change in behavior essentially break backwards compatibility? Perhaps it'd be less scary if ECM's KDECmakeSettings set some var to make KDE software default-opt-out of autogeneration (and then revisit the default behavior for the macro for KF6)?
Then they'd basically be doing it wrong since you're supposed to actually put some effort into creating the appdata file yourself. :)
Perhaps it'd be less scary if ECM's KDECmakeSettings set some var to make KDE software default-opt-out of autogeneration (and then revisit the default behavior for the macro for KF6)?
No strong objection.