While working on #3084983: Move all the code related to path aliases to a new (required) "path_alias" module → we realized that installing a module in an update function should not result in automatically installing entity type/field definitions, because an update function should always install a well-defined set of entity type and definitions, to be repeatable and predictable, whereas the module installer just installs whatever definitions are available in code.
Add a flag to ModuleInstallerInterface::install() to notify that the module installation is happening in the update context, so that entity type/field definition installation can be skipped.
TODO
None
ModuleInstaller[Interface]::install() gets an extra optional $during_update tag. This is also passed to the various other module installation hooks.
This affects any modules extending ModuleInstaller - there are two of these - module_blacklist and disable_modules. disable_modules is abandoned in favour of config_split, module_blacklist is alpha.
There's also one module implementing ModuleInstallerInterface directly, but this is is not actually replacing the module installer so looks like a mis-use of the interface. https://www.drupal.org/project/steam_login →
None
TODO
Postponed: needs info
11.0 🔥
A change record needs to be drafted before an issue is committed. Note: Change records used to be called change notifications.
Issue summaries save everyone time if they are kept up-to-date. See Update issue summary task instructions.
The major change should have a special release note written to summarize the importance of the change. See Write a release note for an issue.
Not all content is available!
It's likely this issue predates Contrib.social: some issue and comment data are missing.
Just following up 1 more if this is still a valid task? If no follow up in 3 months could close out.
I think that @berdir in #15 is right and we should avoid this, modules installing other modules should let the newly installed module handle updates to itself.