One of the Interesting challenges with all the cross-library deprecation visibility control setup.

Let me try to collect requirements:

• Plasma::Package is part of ABI of Plasma API, cannot be removed in normal builds, only made optionally invisible in API when building against
• Plasma::Package is part of ABI of KRunner API, cannot be removed in normal builds, only made optionally invisible in API when building against
• if Plasma::Package is made invisible with Plasma API, it also needs to be invisible with KRunner API

Current patch as proposed has an issue for build time of KRunner itself, because KF_DISABLE_DEPRECATED_BEFORE_AND_AT=0x053f00 results in PLASMA_ENABLE_DEPRECATED_SINCE(5, 28) evaluating to FALSE during the build of KRunner. Which means,the symbol for AbstractRunner::package() will be missing and thus ABI being broken -> not allowed.

At the same time #if PLASMA_ENABLE_DEPRECATED_SINCE(5, 28) with the declaration in the header is needed indeed, as Plasma::Package is only visible to the compiler with this condition, and given consumers of KRunner API have control over that we need to handle it.

So, KF_DISABLE_DEPRECATED_BEFORE_AND_AT=0x053f00 is not possibly in total with KRunner, as its required implementation code has a hard dependency on Plasma API deprecated before that.
Two options:
a) set the module specific PLASMA_DISABLE_DEPRECATED_BEFORE_AND_AT=0x050500 to override the default from the group KF one
b) remove visibility wrappers around originalPlasma::Package API

I personally favour a) here.

Edit: When designing ECMGenerateExportHeader, I also considered adding support for sublib granularity (next to the group and lib as there is now) when it comes to visibility control, so one could have the option to e.g. have overrules for features. And Plasma::Package could then have their own macro set, and here we could limit the exception by some e.g. PLASMA_PACKAGE_DISABLE_DEPRECATED_BEFORE_AND_AT=0x050500 and have the rest of deprecated Plasma API still invisible by the 0x053f00 limit. Something which still could be added on top of what we have now, if there is demand. There is no open end for complexity ;)

Given we have officially deprecated API in KRunner, it should indeed also get ported to ecm_generate_export_header. I would have now done this myself, but actually would like to see other people are easily able to use that macro API, so it's not just something compatible to my state of brain ;)