On Friday, July 10, 2020 6:14:27 PM MST Neal Gompa wrote: > On Fri, Jul 10, 2020 at 8:59 PM John M. Harris Jr <johnmh@xxxxxxxxxxxxx> > wrote: > > > > > > On Friday, July 10, 2020 5:56:31 PM MST Neal Gompa wrote: > > > > > On Fri, Jul 10, 2020 at 8:55 PM John M. Harris Jr > > > <johnmh@xxxxxxxxxxxxx> > > > wrote: > > > > > > > > > > > > > > > > > > > On Thursday, May 28, 2020 12:53:26 PM MST Ben Cotton wrote: > > > > > > > > > > > > > > > > > https://fedoraproject.org/wiki/Changes/drop_mod_php > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > == Summary == > > > > > mod_php (apache2handler) is an optional httpd module to execute PHP > > > > > scripts, not used. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > == Owner == > > > > > * Name: [[User:Remi| Remi Collet]] > > > > > * Email: remi at fedoraproject dot org > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > == Detailed Description == > > > > > By default php-fpm is used for a few versions. mod_php is not > > > > > supported for threaded modules. mod_php usage also increases > > > > > security > > > > > risk, sharing the same process than httpd. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Drop mod_php from php build. This will only affect user of httpd in > > > > > "prefork" mode, which will also use php-fpm. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > php-fpm is already used but most users of httpd and nginx without > > > > > any > > > > > issue. > > > > > > > > > > > > > > > > > > > > > > > > > The "php" package will be kept as a metapackage, installing (weak > > > > > dependencies) most commonly used extension, thus reducing the > > > > > difference between "yum install php" (flat repository) and "yum > > > > > module > > > > > install php" (modular repository). > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > == Benefit to Fedora == > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Only provide the modern way to execute PHP in a web server. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > == Scope == > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > PHP rebuild (mod_php build is already conditional) > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > * Other developers: N/A (not a System Wide Change) > > > > > * Release engineering: N/A > > > > > * Policies and guidelines: N/A (not a System Wide Change) > > > > > * Trademark approval: N/A (not needed for this Change) > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > == Upgrade/compatibility impact == > > > > > N/A (not a System Wide Change) > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > == How To Test == > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > * install and play with your web applications > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > == User Experience == > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > No change. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > == Dependencies == > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > None (dependency on "php" is already forbidden by Guidelines) > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > == Contingency Plan == > > > > > * revert > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > * Contingency deadline: N/A (not a System Wide Change) > > > > > * Blocks release? N/A (not a System Wide Change), Yes/No > > > > > * Blocks product? product > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > == Documentation == > > > > > > > > > > > > > > > > > > > > > > > > Now that this has been accepted, I take it that the current maintainer > > > > of > > > > mod_php no longer wants to maintain it? I'd like to offer to take > > > > over > > > > the > > > > package if that's the case, so that Fedora will continue to work for > > > > those > > > > using mod_php. > > > > > > > > > > > > > > > mod_php is built from the php source tree, so no, you can't really do > > > that. > > > > > > > In that case, is it possible that it can just be kept in the build, so > > that we can continue to support it? There's really not a whole lot of > > reason to kill off something as useful and widely used as mod_php while > > it's still working well for thousands, if not hundreds of thousands, of > > servers, and is still the preferred backend for Apache, which even > > defaults to prefork upstream.> > > > > > Fedora has not defaulted to prefork for Apache httpd since Fedora 27, > upstream Apache httpd has not defaulted to it for even *longer*. > > Apache httpd switched to event mpm by default more than a decade ago > (at least 12 years ago, from what I can tell, most likely longer!). > Fedora finally followed upstream on this in Fedora 27, and mod_php has > been broken in the default configuration since then. > > But even with that, we've had PHP-FPM as the default with Apache httpd > for five years now. Out of the box, that's what is set up. Nobody > noticed that mod_php was broken for the past two years, and nobody has > had any real issues with the default PHP SAPI being switched five > years ago. > > At this point, the only reason to keep it is if there's something that > somehow absolutely cannot run with PHP-FPM but can with mod_php. If > something like that is the case, we *could* restore it as a > subpackage. But it'd have to be a pretty compelling case... Changing the defaults isn't a problem, people who have running systems won't be effected. This will actively break peoples' systems upon update, if mod_php is dropped. It wasn't ever broken, and it's not broken now. -- John M. Harris, Jr. _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
