Describe the Bug

If mpm_event is enabled with apache::mod::event, using apache::mpm::disable_mpm_event will not disable it. Internally, at least on Debian 12, it looks like the event and mpm_event modules are identical, aside from the mpm_event module specifically warning about conflicts with other MPM modules. As a result, I believe it is a bug that the module's method to enable the module is not compatible with the way to disable the module.

Note: I will add a pull request with a patch to fix this behavior; I wanted an issue to link it against.

Expected Behavior

The expected behavior is that the Puppet module can both enable or disable mpm_event, based on variables such as host facts.

Steps to Reproduce

Steps to reproduce the behavior:

1. Apply a manifest to a system that includes mpm_event:

include apache::mod::event

2. Later, apply a different manifest to the same system that disables the same module:

include apache::mpm::disable_mpm_event

3. Module will still be enabled, as the class to enable uses the name without the mpm_ prefix, while the class to disable the module does use the mpm_ prefix.

Environment

• Version 12.1
• Platform Debian 12

Additional Context

The inconsistency is caused by the module being enabled with ${mpm} as `event``:

While the module is disabled with:

This is inconsistent with prefork and worker, which are enabled and disabled without the mpm_ prefix.