[Bug 263655] www/apache24: Remove automatic mpm fallback configuration

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=263655

            Bug ID: 263655
           Summary: www/apache24: Remove automatic mpm fallback
                    configuration
           Product: Ports & Packages
           Version: Latest
          Hardware: Any
                OS: Any
            Status: New
          Severity: Affects Only Me
          Priority: ---
         Component: Individual Port(s)
          Assignee: apache@FreeBSD.org
          Reporter: ports@skyforge.at
          Assignee: apache@FreeBSD.org
             Flags: maintainer-feedback?(apache@FreeBSD.org)

Created attachment 233582
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=233582&action=edit
www/apache24: Remove automatic mpm fallback configuration

I'd like to propose a patch to remove the automatic fallback generation with
mpm_prefork for www/apache24. Currently the apache24 package greps for a
present MPM configuration in http.conf and creates a fallback configuration in
modules.d, which is included by default. I feel that this is problematic for a
variety of reasons:


* It doesn't account for modular configurations: If the loading of an MPM
module takes place in an included configuration (as would be the case for most
modularized configuration schemes, which are increadibly useful and common),
the script generates a fallback configuration that may cause apache to either
load the wrong mpm module on restart, or cause it to fail starting alltogether.

* It doesn't preserve changes to the file: Even if I keep the
000_mpm_prefork_fallback.conf configuration but uncomment the LoadModule
statement, the configuration is simply overwritten on the next
update/reinstallation of the package.

* From a philosophical perspective, it feels like it's overstepping boundaries:
We nowadays ship with a sample configuration that includes a well-intended
default LoadModule statement for mpm_prefork. Whichever way the user decides to
modify and diverge from that default configuration should be up to them.
Creating non-sample configurations in places that would be sourced by default
feels like it's taking things a step too far.

Judging from the commit history, I think there was once a point for this kind
of behaviour to help with the migration from a static to a dynamic MPM backend.
But this was in 2015, so I think it's time to reevaluate this and, perhaps,
move on.

As a minor note: I think the configuration as it stands right now doesn't even
work properly anymore. At least my apache complains with the following:

Syntax error on line 21 of
/usr/local/etc/apache24/modules.d/000_mpm_prefork_fallback.conf: Cannot load
libexec/apache24/mod_mpm_prefork.so into server: Cannot open
"/usr/local/etc/apache24/libexec/apache24/mod_mpm_prefork.so"

I've attached a patch that (I think?) removes this functionality in its
entirety, as it really shouldn't be necessary anymore. All configurations had
ample time migrating and new installations come with a sane default anyway. We
could still preserve a warning on install, but I'm really not sure that's
necessary anymore.

In any case it would make my own personal use case a bit nicer to deal with, as
I have split the individual modules and their configurations in seperate files
in modules.d and currently need to pay attention to this everytime I update
apache24, but I'd love to hear feedback and different opinions on this. :)


Cheers,
Sascha

-- 
You are receiving this mail because:
You are the assignee for the bug.