Re: Fedora 33 Self-Contained Change proposal: Drop mod_php

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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...




--
真実はいつも一つ!/ Always, there's only one truth!
_______________________________________________
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




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux