1bc72f8 started auto-generating a README, but Module::Install doesn't give a super useful error for users when they're creating an RT extension and run 'perl Makefile.PL' for the first time.
As reported by Christian Loos in rt.cpan.org #98243 Fixes an error in the META.yml for rt-extension-ldapimport-multiemail
These allow using modern MIRTx on a 3.8 extension (drop the 4.0.0 minimum version check) and preventing an automatic ReadmeFromPod, useful if your main module file shouldn't overwrite your lovingly crafted README (RTIR).
Inheriting from Module::Install means that, in the presence of a inc/.author file, a BEGIN block is run that clears out inc/. This on purpose, such that the updated Module::Install files can be copied in. However, in the case of the runtime parts of Module::Install::RTx, this meant that running "make initdb" (and now "make install") would clear our inc/ if run as an author -- and replace them with the much smaller set of dependencies that the runtime module needed. Make Module::Install::RTx::Runtime truely runtime-only, by importing it explicitly into inc/, and making it no longer inherit from Module::Install.
We cannot check @Plugins earlier, such as during "perl Makefile.PL" time, because of permissions. "make install", however, does have permissions to read the RT_Config file. The set of prereqs cannot be hardcoded into the call in the Makefile because they are not known yet; only calls to rt_requires_plugin() after the RTx() call will set them up. Thus the only source of the RT plugin prereqs is in the META.yml file; load it and to check that all of the explicit dependencies are enabled. This mirrors existing code in inc::Module::Install::Metadata. The requires_rt line was moved earlier because it also sets a minimum version of perl, which is necessary for ->include_deps to determine what needs to be bundled along with YAML::Tiny in the distribution.
While matching on the error using regexes is somewhat fragile, all supported versions do currently use the same phrasing. Attempting to replicate the entire logic of RT::Config->LoadConfig in order to re-check permissions seems like too high a cost for the rather low chance that we re-word these messages in a stable series -- regardless, the failure mode is no worse than at present: a misleading warning.
$RT::CORE_CONFIG_FILE and $RT::SITE_CONFIG_FILE were removed in 96411640, and thus this section of code has been a no-op since 3.7.1. RT::LoadConfig will die if it cannot load RT_Config.pm, although the message is somewhat misleading, as it refers to "the user/group your webserver is running as" which is irrelevant in this context.
Nearly 4 years is sufficient of a deprecation cycle.