Fedora 33 Self-Contained Change proposal: Drop mod_php

[Ben Cotton]

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




-- 
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis

[John M. Harris Jr]

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 ==
>  
>  
>  
>  
>  -- 
>  Ben Cotton
>  He / Him / His
>  Senior Program Manager, Fedora & CentOS Stream
>  Red Hat
>  TZ=America/Indiana/Indianapolis 
Please do not drop mod_php. It is NOT the case that "php-fpm is already used 
but most users of httpd and nginx without any issue."

If the rationale behind this is a maintenance burden, I would be happy to 
assist with maintaining the package. Many people still use mod_php, in fact 
it's the standard way to configure PHP with Apache on just about every server 
that is currently running. Dropping mod_php will break a good chunk of users' 
existing servers, needlessly.

-- 
John M. Harris, Jr.
Splentity

[Remi Collet]

Le 29/05/2020 à 06:15, John M. Harris Jr a écrit :
>  Please do not drop mod_php. It is NOT the case that "php-fpm is
> already used 
>  but most users of httpd and nginx without any issue." 
php-fpm is the default configuration for httpd and nginx for few versions

nginx ONLY uses php-fpm

mod_php is httpd only and prefork mode only
so without threaded MPM and without http2 support

Please describe issues, I don't have any bug report about this.

Remi

[John M. Harris Jr]

On Thursday, May 28, 2020 11:59:41 PM MST Remi Collet wrote:
>  Le 29/05/2020 à 06:15, John M. Harris Jr a écrit :
>  
>  > Please do not drop mod_php. It is NOT the case that "php-fpm is already
>  > used  but most users of httpd and nginx without any issue."
>  
>  
>  php-fpm is the default configuration for httpd and nginx for few versions
>  
>  nginx ONLY uses php-fpm
>  
>  mod_php is httpd only and prefork mode only
>  so without threaded MPM and without http2 support
>  
>  Please describe issues, I don't have any bug report about this.
>  
>  Remi 
Yes, nginx only uses php-fpm. But that has nothing to do with mod_php.

The default doesn't matter, there's absolutely no reason to take away the 
sysadmin's choice here. There are at least 40 servers I personally am 
responsible for where I see no reason to move from mod_php to php-fpm, for 
example. If you don't want to maintain it, I'd be happy to do so. Many third 
party packages expect mod_php, and nearly all documentation for configuring 
httpd for Fedora, CentOS and RHEL goes through the use of mod_php. There is 
just no reason to break this. People who want php-fpm will stick with it, and 
others will continue to use mod_php as we have for the last decade+. Many 
servers do not need http2, or other new features. Many of us have something 
that works, and we'd like to keep it working.

-- 
John M. Harris, Jr.
Splentity

[Neal Gompa]

On Fri, May 29, 2020 at 4:01 AM John M. Harris Jr <johnmh(a)splentity.com&gt; wrote:
>  On Thursday, May 28, 2020 11:59:41 PM MST Remi Collet wrote:
>  > Le 29/05/2020 à 06:15, John M. Harris Jr a écrit :
>  >
>  > > Please do not drop mod_php. It is NOT the case that "php-fpm is already
>  > > used  but most users of httpd and nginx without any issue."
>  >
>  >
>  > php-fpm is the default configuration for httpd and nginx for few versions
>  >
>  > nginx ONLY uses php-fpm
>  >
>  > mod_php is httpd only and prefork mode only
>  > so without threaded MPM and without http2 support
>  >
>  > Please describe issues, I don't have any bug report about this.
>  >
>  > Remi
>
>  Yes, nginx only uses php-fpm. But that has nothing to do with mod_php.
>
>  The default doesn't matter, there's absolutely no reason to take away the
>  sysadmin's choice here. There are at least 40 servers I personally am
>  responsible for where I see no reason to move from mod_php to php-fpm, for
>  example. If you don't want to maintain it, I'd be happy to do so. Many third
>  party packages expect mod_php, and nearly all documentation for configuring
>  httpd for Fedora, CentOS and RHEL goes through the use of mod_php. There is
>  just no reason to break this. People who want php-fpm will stick with it, and
>  others will continue to use mod_php as we have for the last decade+. Many
>  servers do not need http2, or other new features. Many of us have something
>  that works, and we'd like to keep it working.
>  
As an (oft forgotten!) member of the PHP SIG, I'd like to point out
that part of what we're supposed to do is ship a PHP stack that
minimizes footguns and security nightmares. The PHP stack doesn't make
this easy as it is, and it's been relatively well-known for a while
now that running the interpreter in the same process as the webserver
is a bad idea. Virtually all other programming languages have made
that change in various forms: Python now works through WSGI or ASGI,
Perl uses either PSGI or CGI, Ruby operates through either Unicorn or
Puma typically, and for the past ten years, PHP has strongly
recommended using FastCGI or CGI over mod_php.

It is absolutely a good idea to take away this choice from our builds
when the advice from framework developers, ecosystem experts, and the
upstream developers is to *not* use mod_php. Fedora is in the business
of providing sane defaults and a high-quality package collection. Part
of the quality is removing footguns when they don't need to exist
anymore. We haven't shipped mod_php as the default setup for Apache +
php for several years now, as part of a plan to eventually get rid of
it.



-- 
真実はいつも一つ！/ Always, there's only one truth!

[Igor Raits]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On Fri, 2020-05-29 at 01:00 -0700, John M. Harris Jr wrote:
>  On Thursday, May 28, 2020 11:59:41 PM MST Remi Collet wrote:
>  > Le 29/05/2020 à 06:15, John M. Harris Jr a écrit :
>  > 
>  > > Please do not drop mod_php. It is NOT the case that "php-fpm is
>  > > already
>  > > used  but most users of httpd and nginx without any issue."
>  > 
>  > php-fpm is the default configuration for httpd and nginx for few
>  > versions
>  > 
>  > nginx ONLY uses php-fpm
>  > 
>  > mod_php is httpd only and prefork mode only
>  > so without threaded MPM and without http2 support
>  > 
>  > Please describe issues, I don't have any bug report about this.
>  > 
>  > Remi
>  
>  Yes, nginx only uses php-fpm. But that has nothing to do with
>  mod_php.
>  
>  The default doesn't matter, there's absolutely no reason to take away
>  the 
>  sysadmin's choice here. There are at least 40 servers I personally
>  am 
>  responsible for where I see no reason to move from mod_php to php-
>  fpm, for 
>  example. If you don't want to maintain it, I'd be happy to do so.
>  Many third 
>  party packages expect mod_php, and nearly all documentation for
>  configuring 
>  httpd for Fedora, CentOS and RHEL goes through the use of mod_php.
>  There is 
>  just no reason to break this. People who want php-fpm will stick with
>  it, and 
>  others will continue to use mod_php as we have for the last decade+.
>  Many 
>  servers do not need http2, or other new features. Many of us have
>  something 
>  that works, and we'd like to keep it working. 
That's what CentOS / RHEL is for.

>  -- 
>  John M. Harris, Jr.
>  Splentity
>  
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
>  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/[e-mail] 
- -- 
Igor Raits <ignatenkobrain(a)fedoraproject.org&gt;
> -----BEGIN PGP SIGNATURE-----
>
> iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl7Qxr4ACgkQEV1auJxc
> Hh6GIRAAt5sV7J4E6W5vzHCc3iy+IGXYyMtl/RqewhkcHChT5ZuiCLnOqmBw0vbF
> Mrmn+6hyJUoP4Vfw1uRjbqvt5b3/0V+43ZibIwDNwi7jGSPVazgHUTdhvgqEiqhK
> +tWfLrwaoLMQZoCvMNFqoRnKvmDN/go1IhmHj7HAhhb6VLmGeJ2RJCqQH9hgMUwv
> 9P+aUGoqO5XDFApCGtU55dtIIecPiN5Sd+lHvFRxI5cTJafsU1cLjtqvmayVaPH2
> jeS5nOEFauCuZztCrYBgwgB1OKKudfj9skkb3KlH5VzoH4uSxli4xUccYFnu3Nnq
> uz3J7L4W4sVc5cuhOZuQ+0GmKImY1bfrEj8FFhaVfLPU7qIXPe2zXVWrMC0FaBuD
> Vtkb3d+++Pfmz2Hbs8O9ufo8ahya751f55BQrJOkLq9ncyDjyUCXgmV6Uef+VSJM
> BuHRJjLTmH2i14z4hLNaila0QqOzPEg4ZpjlSOe4U1hG0UMkWqU/U3WGhTBw3dki
> 4sDGon85M1VOw3kDf9wyLzq0fUOvyFLOnDDewwxprWzB0W5J1j30reF9mnAiTzdJ
> mOOas+n8tLNYfCpMkClmg1YB8gO6AFdvD+45GTseYOzGo4hkBcsQcCbj1uQCi7rf
> 0W2MVWh5ioeluvA47/x9WbSEJ6sBrVMSoBp9lW7bDEb+WBm85cA=
> =oY/3
> -----END PGP SIGNATURE-----

[John M. Harris Jr]

On Friday, May 29, 2020 1:24:30 AM MST Igor Raits wrote:
>  On Fri, 2020-05-29 at 01:00 -0700, John M. Harris Jr wrote:
>  
>  > On Thursday, May 28, 2020 11:59:41 PM MST Remi Collet wrote:
>  > 
>  > > Le 29/05/2020 à 06:15, John M. Harris Jr a écrit :
>  > >
>  > > > Please do not drop mod_php. It is NOT the case that "php-fpm is
>  > > > already
>  > > > used  but most users of httpd and nginx without any issue."
>  > >
>  > > php-fpm is the default configuration for httpd and nginx for few
>  > > versions
>  > >
>  > > nginx ONLY uses php-fpm
>  > >
>  > > mod_php is httpd only and prefork mode only
>  > > so without threaded MPM and without http2 support
>  > >
>  > > Please describe issues, I don't have any bug report about this.
>  > >
>  > > Remi
>  >
>  > Yes, nginx only uses php-fpm. But that has nothing to do with
>  > mod_php.
>  >
>  > The default doesn't matter, there's absolutely no reason to take away
>  > the
>  > sysadmin's choice here. There are at least 40 servers I personally
>  > am
>  > responsible for where I see no reason to move from mod_php to php-
>  > fpm, for
>  > example. If you don't want to maintain it, I'd be happy to do so.
>  > Many third
>  > party packages expect mod_php, and nearly all documentation for
>  > configuring
>  > httpd for Fedora, CentOS and RHEL goes through the use of mod_php.
>  > There is
>  > just no reason to break this. People who want php-fpm will stick with
>  > it, and
>  > others will continue to use mod_php as we have for the last decade+.
>  > Many
>  > servers do not need http2, or other new features. Many of us have
>  > something
>  > that works, and we'd like to keep it working.
>  
>  That's what CentOS / RHEL is for. 
Are you saying that you believe Fedora is not suitable for long-term use? I 
really don't know why that would be, other than yanking out packages while 
they still work. However, this will have an affect on CentOS / RHEL as well, 
if it's removed from Fedora, it'll likely be removed there upon the next 
release. With that in mind, that's yet another reason this package should not 
be removed from Fedora. It'll break configs of the hundreds/thousands of users 
of Fedora's downstream projects, as well as a few hundred Fedora users.

This is a change that will seriously break a lot of peoples' config during 
their next system-upgrade, absolutely needlessly. That it's not the default 
already negates any perceived security issues.

-- 
John M. Harris, Jr.
Splentity

[Zbigniew Jędrzejewski-Szmek]

On Thu, May 28, 2020 at 03:53:26PM -0400, Ben Cotton wrote:
>  == 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. 
Based on the replies downthread, it seems that some people are still
using it and want to keep it...

Is mod_php a maintainance burder and/or a noticable installation
overhead when not used? And if it is, would additional help with the
maintainance that was offered make it easier to keep?

Zbyszek

[Alexander Ploumistos]

On Sat, May 30, 2020 at 11:14 AM Zbigniew Jędrzejewski-Szmek
<zbyszek(a)in.waw.pl&gt; wrote:
>  On Thu, May 28, 2020 at 03:53:26PM -0400, Ben Cotton wrote:
>  > == 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.
>
>  Based on the replies downthread, it seems that some people are still
>  using it and want to keep it... 
While I can most definitely sympathize with anyone who will have to
reconfigure servers that were set up years ago, the reality of the
matter is that mod_php is still being used because there's a ton of
guides out there blindly copying over instructions and configuration
snippets for years. The complexity of the stack is such that people
are still oblivious of php-fpm nearly a decade after its introduction.
Security issues aside, a medium-size web server using mod_php will
require roughly 100 times the memory used for the same number of
threads with php-fpm. This is a complete waste of resources. The only
real-world application where it makes sense to prefer mod_php over
php-fpm is a server dedicated to serving only php - no CSS, images,
HTML or anything else. I'd argue this use case is quite rare nowadays.

[Remi Collet]

Le 30/05/2020 à 11:13, Zbigniew Jędrzejewski-Szmek a écrit :

>  Is mod_php a maintainance burder and/or a noticable installation
>  overhead when not used? And if it is, would additional help with the
>  maintainance that was offered make it easier to keep? 
Its maintainance is not much work, the problem is with its support.

Is it reasonable to maintain something only used by a few people ?

More, It will forbid to improve some packaging in web app
relying on the use of FPM and its pool configuration.

E.g. 1 webapp using a dedicated pool, with specific configuration
and running a dedicated user for security purpose, instead of all
webapps running under the same default user account.


Remi

[Joe Orton]

On Sat, May 30, 2020 at 11:13:35AM +0200, Zbigniew Jędrzejewski-Szmek wrote:
>  On Thu, May 28, 2020 at 03:53:26PM -0400, Ben Cotton wrote:
>  > == 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.
>  
>  Based on the replies downthread, it seems that some people are still
>  using it and want to keep it... 
If the existence of non-zero user demand blocked removal of defunct 
technology in Fedora I guess we'd still be shipping SysV init.  

We made the switch from forked-httpd + mod_php to threaded-httpd +
php-fpm by default in Fedora 27, so we've spread this transition over 
six full release cycles.  We've	had AFAIK *zero* bug reports about
making the default switch.

>  Is mod_php a maintainance burder and/or a noticable installation
>  overhead when not used? And if it is, would additional help with the
>  maintainance that was offered make it easier to keep? 
I'm not seeing any technical argument in this thread to support keeping 
mod_php.  If there were, that would be interesting, but otherwise I 
think the package owner should be trusted and empowered to make this 
change.

Regards, Joe

[John M. Harris Jr]

On Tuesday, June 2, 2020 2:05:01 AM MST Joe Orton wrote:
>  On Sat, May 30, 2020 at 11:13:35AM +0200, Zbigniew
> Jędrzejewski-Szmek
>  wrote:
>  > On Thu, May 28, 2020 at 03:53:26PM -0400, Ben Cotton wrote:
>  > 
>  > > == 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.
>  
>  > 
>  > Based on the replies downthread, it seems that some people are still
>  > using it and want to keep it...
>  
>  
>  If the existence of non-zero user demand blocked removal of defunct 
>  technology in Fedora I guess we'd still be shipping SysV init.  
>  
>  We made the switch from forked-httpd + mod_php to threaded-httpd +
>  php-fpm by default in Fedora 27, so we've spread this transition over 
>  six full release cycles.  We've	had AFAIK *zero* bug reports about
>  making the default switch.
>  
>  
>  > Is mod_php a maintainance burder and/or a noticable installation
>  > overhead when not used? And if it is, would additional help with the
>  > maintainance that was offered make it easier to keep?
>  
>  
>  I'm not seeing any technical argument in this thread to support keeping 
>  mod_php.  If there were, that would be interesting, but otherwise I 
>  think the package owner should be trusted and empowered to make this 
>  change.
>  
>  Regards, Joe 
If it's dropped, it wouldn't really be possible for me to make a mod_php 
package to replace it due to the integration, so I can't really see a way of 
keeping a compat package if it's removed, and keeping it around doesn't break 
anything.

-- 
John M. Harris, Jr.

[Peter Pentchev]

On Tue, Jun 02, 2020 at 07:47:12PM -0700, John M. Harris Jr wrote:
>  On Tuesday, June 2, 2020 2:05:01 AM MST Joe Orton wrote:
>  > On Sat, May 30, 2020 at 11:13:35AM +0200, Zbigniew Jędrzejewski-Szmek
>  > wrote:
>  > > On Thu, May 28, 2020 at 03:53:26PM -0400, Ben Cotton wrote:
>  > > 
>  > > > == 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.
>  > 
>  > > 
>  > > Based on the replies downthread, it seems that some people are still
>  > > using it and want to keep it...
>  > 
>  > 
>  > If the existence of non-zero user demand blocked removal of defunct 
>  > technology in Fedora I guess we'd still be shipping SysV init.  
>  > 
>  > We made the switch from forked-httpd + mod_php to threaded-httpd +
>  > php-fpm by default in Fedora 27, so we've spread this transition over 
>  > six full release cycles.  We've	had AFAIK *zero* bug reports about
>  > making the default switch.
>  > 
>  > 
>  > > Is mod_php a maintainance burder and/or a noticable installation
>  > > overhead when not used? And if it is, would additional help with the
>  > > maintainance that was offered make it easier to keep?
>  > 
>  > 
>  > I'm not seeing any technical argument in this thread to support keeping 
>  > mod_php.  If there were, that would be interesting, but otherwise I 
>  > think the package owner should be trusted and empowered to make this 
>  > change.
>  > 
>  > Regards, Joe
>  
>  If it's dropped, it wouldn't really be possible for me to make a mod_php 
>  package to replace it due to the integration, so I can't really see a way of 
>  keeping a compat package if it's removed, and keeping it around doesn't break 
>  anything. 
Do you have an application that absolutely cannot work using php-fpm, or
is it a matter of "must set some time aside to migrate and test
everything after a switch from mod_php to fpm"?

If it's the first, people have repeatedly stated that they want to know
what it is and why. Also, people have repeatedly stated that mod_php is
strongly recommended against by upstream. Also, people have repeatedly
stated that having to support mod_php blocks future work.

If it is the second, unfortunately that is true of many changes.
Sometimes we have to do some work to adapt to a new, better way of doing
things. Sometimes we can see at once that the new way is indeed better;
sometimes it takes us months or even years to realize that. And yes,
there may be particular circumstances when the benefits of the new way
do not really outweigh the benefits that the old way provided, but it is
not easy for me to imagine a situation when a switch from mod_php to
php-fpm would break things. Yes, I can, yes, I know that one can install
more modules, make some PHP applications use shared server memory and
whatnot; still, it seems to me that ultimately there are better ways to
handle most of these.

The vast, overwhelming majority of installations do not *need* mod_php.

The vast, overwhelming majority of installations would *benefit* from
a switch to php-fpm.

The vast, overwhelming majority of installations *currently* using
mod_php are doing it because of conventional wisdom ("this is the way to
set up a PHP site") that is rooted in the times when php-fpm
*did not exist* - so it's much more of "this was the only possible way
to set up a PHP site back then" than "this is the best way to set up
a PHP site now".

Yep, migration needs work. Acknowledged. The same could be said of
changing an init system, changing a default syslog implementation,
changing the way a database server is configured, changing the defaults
for a proxy server's configuration... and so many more.

G'luck,
Peter

-- 
Peter Pentchev  roam(a)ringlet.net roam(a)debian.org pp(a)storpool.com
PGP key:        http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint 2EE7 A7A5 17FC 124C F115  C354 651E EFB0 2527 DF13

[Carl George]

I think it would be a better idea to move mod_php (the software) to a
literal mod_php subpackage that is marked as deprecated [0].  As the
deprecation policy states, this would allow the package to be kept around
for compatibility purposes prior to being outright removed at some point in
the future.  This would address the support burden by setting expectations
around that subpackage.  Any bugs filed against mod_php could just be closed
with a reminder that it is deprecated and a recommendation to switch to
php-fpm.  Webapps packaged in Fedora would be free to focus on integration
with php-fpm and could completely ignore mod_php.

I actually suggested this back in 2015 [1] (minus the deprecation part), but
it has been repeatedly declined.  The current naming scheme causes lots of
user confusion, as well as not being compliant with the package naming
policy [2].

[0] https://docs.fedoraproject.org/en-US/packaging-guidelines/deprecating-pac...
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1290267
[2] https://docs.fedoraproject.org/en-US/packaging-guidelines/Naming/#_httpd_...

On Wed, Jun 3, 2020 at 1:00 AM Peter Pentchev <roam(a)ringlet.net&gt; wrote:
>  On Tue, Jun 02, 2020 at 07:47:12PM -0700, John M. Harris Jr wrote:
>  > On Tuesday, June 2, 2020 2:05:01 AM MST Joe Orton wrote:
>  > > On Sat, May 30, 2020 at 11:13:35AM +0200, Zbigniew Jędrzejewski-Szmek
>  > > wrote:
>  > > > On Thu, May 28, 2020 at 03:53:26PM -0400, Ben Cotton wrote:
>  > > >
>  > > > > == 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.
>  > >
>  > > >
>  > > > Based on the replies downthread, it seems that some people are still
>  > > > using it and want to keep it...
>  > >
>  > >
>  > > If the existence of non-zero user demand blocked removal of defunct
>  > > technology in Fedora I guess we'd still be shipping SysV init.
>  > >
>  > > We made the switch from forked-httpd + mod_php to threaded-httpd +
>  > > php-fpm by default in Fedora 27, so we've spread this transition over
>  > > six full release cycles.  We've     had AFAIK *zero* bug reports about
>  > > making the default switch.
>  > >
>  > >
>  > > > Is mod_php a maintainance burder and/or a noticable installation
>  > > > overhead when not used? And if it is, would additional help with the
>  > > > maintainance that was offered make it easier to keep?
>  > >
>  > >
>  > > I'm not seeing any technical argument in this thread to support keeping
>  > > mod_php.  If there were, that would be interesting, but otherwise I
>  > > think the package owner should be trusted and empowered to make this
>  > > change.
>  > >
>  > > Regards, Joe
>  >
>  > If it's dropped, it wouldn't really be possible for me to make a mod_php
>  > package to replace it due to the integration, so I can't really see a way of
>  > keeping a compat package if it's removed, and keeping it around doesn't
> break
>  > anything.
>
>  Do you have an application that absolutely cannot work using php-fpm, or
>  is it a matter of "must set some time aside to migrate and test
>  everything after a switch from mod_php to fpm"?
>
>  If it's the first, people have repeatedly stated that they want to know
>  what it is and why. Also, people have repeatedly stated that mod_php is
>  strongly recommended against by upstream. Also, people have repeatedly
>  stated that having to support mod_php blocks future work.
>
>  If it is the second, unfortunately that is true of many changes.
>  Sometimes we have to do some work to adapt to a new, better way of doing
>  things. Sometimes we can see at once that the new way is indeed better;
>  sometimes it takes us months or even years to realize that. And yes,
>  there may be particular circumstances when the benefits of the new way
>  do not really outweigh the benefits that the old way provided, but it is
>  not easy for me to imagine a situation when a switch from mod_php to
>  php-fpm would break things. Yes, I can, yes, I know that one can install
>  more modules, make some PHP applications use shared server memory and
>  whatnot; still, it seems to me that ultimately there are better ways to
>  handle most of these.
>
>  The vast, overwhelming majority of installations do not *need* mod_php.
>
>  The vast, overwhelming majority of installations would *benefit* from
>  a switch to php-fpm.
>
>  The vast, overwhelming majority of installations *currently* using
>  mod_php are doing it because of conventional wisdom ("this is the way to
>  set up a PHP site") that is rooted in the times when php-fpm
>  *did not exist* - so it's much more of "this was the only possible way
>  to set up a PHP site back then" than "this is the best way to set up
>  a PHP site now".
>
>  Yep, migration needs work. Acknowledged. The same could be said of
>  changing an init system, changing a default syslog implementation,
>  changing the way a database server is configured, changing the defaults
>  for a proxy server's configuration... and so many more.
>
>  G'luck,
>  Peter
>
>  --
>  Peter Pentchev  roam(a)ringlet.net roam(a)debian.org pp(a)storpool.com
>  PGP key:        http://people.FreeBSD.org/~roam/roam.key.asc
>  Key fingerprint 2EE7 A7A5 17FC 124C F115  C354 651E EFB0 2527 DF13
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
>  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/[e-mail] 


-- 
Carl George

[Remi Collet]

Le 04/06/2020 à 19:42, Carl George a écrit :
>  I think it would be a better idea to move mod_php (the software) to
> a
>  literal mod_php subpackage that is marked as deprecated [0].  
Sorry, but I won't do that.
Never.

We are focusing since ever to provide proper configuration
working out of the box.

Since always (before Fedora Core 1)

"php" means the language (with is most used SAPI)

* httpd + php works out of the box

For a long time (around F 20)

* httpd + php-fpm works out of the box
* nginx + php-fpm works out of the box

Since F 27, FPM is the default configuration
Most people don't even noticed the change

So I WON'T provide a broken configuration
as "httpd + mod_php" will NOT work.


The change is about dropping mod_php, so, sorry,
but this discussion about package name is out of topic.



Regars,
Remi


P.S. I also think changing well known package layout
for a "few" versions doesn't make any sense, will
only add a bit more confusion for users.

[John M. Harris Jr]

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.

-- 
John M. Harris, Jr.

[Neal Gompa]

On Fri, Jul 10, 2020 at 8:55 PM John M. Harris Jr <johnmh(a)splentity.com&gt; 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.



-- 
真実はいつも一つ！/ Always, there's only one truth!

[John M. Harris Jr]

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(a)splentity.com&gt;
>  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.

-- 
John M. Harris, Jr.

[Neal Gompa]

On Fri, Jul 10, 2020 at 8:59 PM John M. Harris Jr <johnmh(a)splentity.com&gt; 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(a)splentity.com&gt;
>  > 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!

[John M. Harris Jr]

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(a)splentity.com&gt;
>  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(a)splentity.com&gt;
>  > > 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.

[Neal Gompa]

On Fri, Jul 10, 2020 at 9:26 PM John M. Harris Jr <johnmh(a)splentity.com&gt; wrote:
>  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(a)splentity.com&gt;
>  > 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(a)splentity.com&gt;
>  > > > 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.
>  
Sorry, no. You need to be more convincing than that.

Unless you went out of your way to change the apache configuration
snippet we ship for apache httpd, then you would seamlessly switch to
FPM as soon as you installed it and activated the service. And if you
*did* go out of your way to change it, then you can go change it again
to work with PHP-FPM.



-- 
真実はいつも一つ！/ Always, there's only one truth!

[John M. Harris Jr]

On Friday, July 10, 2020 6:31:08 PM MST Neal Gompa wrote:
>  On Fri, Jul 10, 2020 at 9:26 PM John M. Harris Jr
> <johnmh(a)splentity.com&gt;
>  wrote:
>  >
>  >
>  > 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(a)splentity.com&gt;
>  > > 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(a)splentity.com&gt;
>  > > > > 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.
>  >
>  >
>  
>  
>  Sorry, no. You need to be more convincing than that.
>  
>  Unless you went out of your way to change the apache configuration
>  snippet we ship for apache httpd, then you would seamlessly switch to
>  FPM as soon as you installed it and activated the service. And if you
>  *did* go out of your way to change it, then you can go change it again
>  to work with PHP-FPM. 
My systems never had php-fpm, and certainly didn't get it upon upgrading. 
They've been running just fine for years. I don't see any reason to lose 
performance to php-fpm's overhead, and lose the stability of mod_php.

The only system I have running with php-fpm is one where I installed a PHP app 
which is packaged in Fedora.

Again, there's no technical debt kept by just continuing to build and ship 
mod_php. I'm not asking you to provide support for it, and I'm happy to tackle 
any bugs found with it, not that I suspect there will be any.  I'm far from 
the only user that has systems still running on mod_php. If this goes through, 
upon upgrade to Fedora 33, these users' systems will cease to function 
properly.

-- 
John M. Harris, Jr.

[Neal Gompa]

On Fri, Jul 10, 2020 at 9:38 PM John M. Harris Jr <johnmh(a)splentity.com&gt; wrote:
>  On Friday, July 10, 2020 6:31:08 PM MST Neal Gompa wrote:
>  > On Fri, Jul 10, 2020 at 9:26 PM John M. Harris Jr <johnmh(a)splentity.com&gt;
>  > wrote:
>  > >
>  > >
>  > > 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(a)splentity.com&gt;
>  > > > 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(a)splentity.com&gt;
>  > > > > > 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.
>  > >
>  > >
>  >
>  >
>  > Sorry, no. You need to be more convincing than that.
>  >
>  > Unless you went out of your way to change the apache configuration
>  > snippet we ship for apache httpd, then you would seamlessly switch to
>  > FPM as soon as you installed it and activated the service. And if you
>  > *did* go out of your way to change it, then you can go change it again
>  > to work with PHP-FPM.
>
>  My systems never had php-fpm, and certainly didn't get it upon upgrading.
>  They've been running just fine for years. I don't see any reason to lose
>  performance to php-fpm's overhead, and lose the stability of mod_php.
>  
What are you talking about? In almost every case I've ever seen or
used, PHP-FPM is *more performant* than mod_php. I work for a company
that writes an absurd amount of complex PHP software. We switched from
mod_php to PHP-FPM everywhere *four years ago* for *performance* and
*stability*. Decoupling the interpreter from the web server improves
the reliability of the stack and makes it easier for code execution
and presentation to perform at optimum levels. Moreover, it becomes
possible to reuse the same FPM instance for multiple applications
across multiple web servers, which is incredibly useful.

>  The only system I have running with php-fpm is one where I installed
> a PHP app
>  which is packaged in Fedora.
>  
Then just switch everything else. It's not that hard.

>  Again, there's no technical debt kept by just continuing to build
> and ship
>  mod_php. I'm not asking you to provide support for it, and I'm happy to tackle
>  any bugs found with it, not that I suspect there will be any.  I'm far from
>  the only user that has systems still running on mod_php. If this goes through,
>  upon upgrade to Fedora 33, these users' systems will cease to function
>  properly.
>  
I *just* outlined the problems with shipping mod_php. You can continue
to blithely ignore them at your own peril.



-- 
真実はいつも一つ！/ Always, there's only one truth!

[John M. Harris Jr]

On Friday, July 10, 2020 6:43:59 PM MST Neal Gompa wrote:
>  On Fri, Jul 10, 2020 at 9:38 PM John M. Harris Jr
> <johnmh(a)splentity.com&gt;
>  wrote:
>  >
>  >
>  > On Friday, July 10, 2020 6:31:08 PM MST Neal Gompa wrote:
>  > 
>  > > On Fri, Jul 10, 2020 at 9:26 PM John M. Harris Jr
>  > > <johnmh(a)splentity.com&gt;
>  > > wrote:
>  > > 
>  > > >
>  > > >
>  > > >
>  > > > 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(a)splentity.com&gt;
>  > > > > 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(a)splentity.com&gt;
>  > > > > > > 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.
>  > > >
>  > > >
>  > > >
>  > >
>  > >
>  > >
>  > >
>  > > Sorry, no. You need to be more convincing than that.
>  > >
>  > >
>  > >
>  > > Unless you went out of your way to change the apache configuration
>  > > snippet we ship for apache httpd, then you would seamlessly switch to
>  > > FPM as soon as you installed it and activated the service. And if you
>  > > *did* go out of your way to change it, then you can go change it again
>  > > to work with PHP-FPM.
>  >
>  >
>  >
>  > My systems never had php-fpm, and certainly didn't get it upon upgrading.
>  > They've been running just fine for years. I don't see any reason to lose
>  > performance to php-fpm's overhead, and lose the stability of mod_php.
>  >
>  >
>  
>  
>  What are you talking about? In almost every case I've ever seen or
>  used, PHP-FPM is *more performant* than mod_php. I work for a company
>  that writes an absurd amount of complex PHP software. We switched from
>  mod_php to PHP-FPM everywhere *four years ago* for *performance* and
>  *stability*. Decoupling the interpreter from the web server improves
>  the reliability of the stack and makes it easier for code execution
>  and presentation to perform at optimum levels. Moreover, it becomes
>  possible to reuse the same FPM instance for multiple applications
>  across multiple web servers, which is incredibly useful. 
Because of FastCGI, php-fpm adds ~1ms to every request, and I'm not the only 
one that's measured similar results. Most systems running a web server only 
run one webserver, generally either just apache or just nginx, so I don't see 
the benefit to that either.

>  > The only system I have running with php-fpm is one where I
> installed a PHP
>  > app which is packaged in Fedora.
>  >
>  >
>  
>  
>  Then just switch everything else. It's not that hard. 
Why should I have to switch the system that's being used, and potentially 
break these servers, just because a package isn't being compiled anymore? It 
still works, and it works very well. It has less overhead than php-fpm, even!

>  > Again, there's no technical debt kept by just continuing to
> build and
>  > ship
>  > mod_php. I'm not asking you to provide support for it, and I'm happy to
>  > tackle any bugs found with it, not that I suspect there will be any. 
>  > I'm far from the only user that has systems still running on mod_php. If
>  > this goes through, upon upgrade to Fedora 33, these users' systems will
>  > cease to function properly.
>  >
>  >
>  
>  
>  I *just* outlined the problems with shipping mod_php. You can continue
>  to blithely ignore them at your own peril. 
I'm sorry, but I don't see that in the email I'm responding to, the email you

send just before that, or the root of this thread. What are the actual 
problems with shipping mod_php? I'm not talking about "benefits" of using
php-
fpm, but the problems with shipping mod_php? I'd be happy to help solve them, 
so that users such as myself and the others using mod_php can continue to do 
so.

-- 
John M. Harris, Jr.

[Gary Buhrmaster]

On Sat, Jul 11, 2020 at 1:50 AM John M. Harris Jr <johnmh(a)splentity.com&gt; wrote:

>  Why should I have to switch the system that's being used, and potentially
>  break these servers, just because a package isn't being compiled anymore? It
>  still works, and it works very well. It has less overhead than php-fpm, even!
>  
AFAICT you do not.  You are absolutely free to build
your own rpms and use them on your own systems.
I do that for a couple of very specific applications
that have no value outside of my personal use case,
and did that for years at a previous $DAYJOB for
the site.

[John M. Harris Jr]

On Friday, July 10, 2020 6:56:36 PM MST Gary Buhrmaster wrote:
>  On Sat, Jul 11, 2020 at 1:50 AM John M. Harris Jr
> <johnmh(a)splentity.com&gt;
>  wrote: 
 
>  
>  >
>  >
>  > Why should I have to switch the system that's being used, and potentially
>  > break these servers, just because a package isn't being compiled anymore?
>  > It still works, and it works very well. It has less overhead than
>  > php-fpm, even!>
>  >
>  
>  
>  AFAICT you do not.  You are absolutely free to build
>  your own rpms and use them on your own systems.
>  I do that for a couple of very specific applications
>  that have no value outside of my personal use case,
>  and did that for years at a previous $DAYJOB for
>  the site. 
What would be the best way to do that, such that all Fedora users can make use 
of it? Otherwise, this is going to break peoples' systems on upgrade to Fedora 
33, so we need to solve this problem fairly quickly. I originally considered 
cloning the current php package over to copr when the change was accepted, but 
that'd only be useful for those that are aware their systems are about to be 
needlessly broken.

-- 
John M. Harris, Jr.

[Neal Gompa]

On Fri, Jul 10, 2020 at 10:05 PM John M. Harris Jr <johnmh(a)splentity.com&gt; wrote:
>  On Friday, July 10, 2020 6:56:36 PM MST Gary Buhrmaster wrote:
>  > On Sat, Jul 11, 2020 at 1:50 AM John M. Harris Jr <johnmh(a)splentity.com&gt;
>  > wrote:
>
>  >
>  > >
>  > >
>  > > Why should I have to switch the system that's being used, and potentially
>  > > break these servers, just because a package isn't being compiled anymore?
>  > > It still works, and it works very well. It has less overhead than
>  > > php-fpm, even!>
>  > >
>  >
>  >
>  > AFAICT you do not.  You are absolutely free to build
>  > your own rpms and use them on your own systems.
>  > I do that for a couple of very specific applications
>  > that have no value outside of my personal use case,
>  > and did that for years at a previous $DAYJOB for
>  > the site.
>
>  What would be the best way to do that, such that all Fedora users can make use
>  of it? Otherwise, this is going to break peoples' systems on upgrade to Fedora
>  33, so we need to solve this problem fairly quickly. I originally considered
>  cloning the current php package over to copr when the change was accepted, but
>  that'd only be useful for those that are aware their systems are about to be
>  needlessly broken.
>  
Copr is the way to go if you really want to provide it. You can
probably start from here:
https://src.fedoraproject.org/rpms/php/pull-request/4

But as described in the PR by Remi, mod_php + httpd is essentially a broken
configuration.




--
真実はいつも一つ！/ Always, there's only one truth!

[drago01]

On Saturday, July 11, 2020, John M. Harris Jr <johnmh(a)splentity.com&gt; wrote:

>  On Friday, July 10, 2020 6:43:59 PM MST Neal Gompa wrote:
>  > On Fri, Jul 10, 2020 at 9:38 PM John M. Harris Jr <johnmh(a)splentity.com&gt;
>  > wrote:
>  > >
>  > >
>  > > On Friday, July 10, 2020 6:31:08 PM MST Neal Gompa wrote:
>  > >
>  > > > On Fri, Jul 10, 2020 at 9:26 PM John M. Harris Jr
>  > > > <johnmh(a)splentity.com&gt;
>  > > > wrote:
>  > > >
>  > > > >
>  > > > >
>  > > > >
>  > > > > 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(a)splentity.com&gt;
>  > > > > > 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(a)splentity.com&gt;
>  > > > > > > > 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.
>  > > > >
>  > > > >
>  > > > >
>  > > >
>  > > >
>  > > >
>  > > >
>  > > > Sorry, no. You need to be more convincing than that.
>  > > >
>  > > >
>  > > >
>  > > > Unless you went out of your way to change the apache configuration
>  > > > snippet we ship for apache httpd, then you would seamlessly switch to
>  > > > FPM as soon as you installed it and activated the service. And if you
>  > > > *did* go out of your way to change it, then you can go change it
>  again
>  > > > to work with PHP-FPM.
>  > >
>  > >
>  > >
>  > > My systems never had php-fpm, and certainly didn't get it upon
>  upgrading.
>  > > They've been running just fine for years. I don't see any reason to
>  lose
>  > > performance to php-fpm's overhead, and lose the stability of mod_php.
>  > >
>  > >
>  >
>  >
>  > What are you talking about? In almost every case I've ever seen or
>  > used, PHP-FPM is *more performant* than mod_php. I work for a company
>  > that writes an absurd amount of complex PHP software. We switched from
>  > mod_php to PHP-FPM everywhere *four years ago* for *performance* and
>  > *stability*. Decoupling the interpreter from the web server improves
>  > the reliability of the stack and makes it easier for code execution
>  > and presentation to perform at optimum levels. Moreover, it becomes
>  > possible to reuse the same FPM instance for multiple applications
>  > across multiple web servers, which is incredibly useful.
>
>  Because of FastCGI, php-fpm adds ~1ms to every request, and I'm not the
>  only
>  one that's measured similar results. Most systems running a web server
>  only
>  run one webserver, generally either just apache or just nginx, so I don't
>  see
>  the benefit to that either. 

 https://www.cloudways.com/blog/php-fpm-on-cloud/



>  > > The only system I have running with php-fpm is one where I
> installed a
>  PHP
>  > > app which is packaged in Fedora.
>  > >
>  > >
>  >
>  >
>  > Then just switch everything else. It's not that hard.
>
>  Why should I have to switch the system that's being used, and potentially
>  break these servers, just because a package isn't being compiled anymore?
>  It
>  still works, and it works very well. It has less overhead than php-fpm,
>  even!
>
>  
It's not it's the opposite (see above) - you seem to be always opposed to
changes in way to not even try to get the benefits of said changes.

[John M. Harris Jr]

On Friday, July 10, 2020 7:12:50 PM MST Neal Gompa wrote:
>  On Fri, Jul 10, 2020 at 10:05 PM John M. Harris Jr
> <johnmh(a)splentity.com&gt;
>  wrote:
>  >
>  >
>  > On Friday, July 10, 2020 6:56:36 PM MST Gary Buhrmaster wrote:
>  > 
>  > > On Sat, Jul 11, 2020 at 1:50 AM John M. Harris Jr
>  > > <johnmh(a)splentity.com&gt;
>  > > wrote:
>  >
>  >
>  >
>  > >
>  > >
>  > > >
>  > > >
>  > > >
>  > > > Why should I have to switch the system that's being used, and
>  > > > potentially
>  > > > break these servers, just because a package isn't being compiled
>  > > > anymore?
>  > > > It still works, and it works very well. It has less overhead than
>  > > > php-fpm, even!>
>  > > >
>  > > >
>  > >
>  > >
>  > >
>  > >
>  > > AFAICT you do not.  You are absolutely free to build
>  > > your own rpms and use them on your own systems.
>  > > I do that for a couple of very specific applications
>  > > that have no value outside of my personal use case,
>  > > and did that for years at a previous $DAYJOB for
>  > > the site.
>  >
>  >
>  >
>  > What would be the best way to do that, such that all Fedora users can make
>  > use of it? Otherwise, this is going to break peoples' systems on upgrade
>  > to Fedora 33, so we need to solve this problem fairly quickly. I
>  > originally considered cloning the current php package over to copr when
>  > the change was accepted, but that'd only be useful for those that are
>  > aware their systems are about to be needlessly broken.
>  >
>  >
>  
>  
>  Copr is the way to go if you really want to provide it. You can
>  probably start from here:
>  https://src.fedoraproject.org/rpms/php/pull-request/4
>  
>  But as described in the PR by Remi, mod_php + httpd is essentially a broken
>  configuration. 
Nowhere in there does it describe how mod_php + httpd would be a broken 
configuration, and it's not. I see where remi mentions that, but that's simply 
not the case. mod_php works just fine, as it has for over a decade, and will 
for many years to come.

It's a damn shame that your PR was closed, that looks like the best way to 
handle the situation to me, drop it into a sub-package.

-- 
John M. Harris, Jr.

[John M. Harris Jr]

On Friday, July 10, 2020 9:41:48 PM MST drago01 wrote:
>  On Saturday, July 11, 2020, John M. Harris Jr
> <johnmh(a)splentity.com&gt; wrote:
>  > On Friday, July 10, 2020 6:43:59 PM MST Neal Gompa wrote:
>  > > On Fri, Jul 10, 2020 at 9:38 PM John M. Harris Jr <johnmh(a)splentity.com&gt;
>  > > 
>  > > wrote:
>  > > > On Friday, July 10, 2020 6:31:08 PM MST Neal Gompa wrote:
>  > > > > On Fri, Jul 10, 2020 at 9:26 PM John M. Harris Jr
>  > > > > <johnmh(a)splentity.com&gt;
>  > > > > 
>  > > > > wrote:
>  > > > > > 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(a)splentity.com&gt;
>  > > > > > > 
>  > > > > > > 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(a)splentity.com&gt;
>  > > > > > > > > 
>  > > > > > > > > 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.
>  > > > > 
>  > > > > Sorry, no. You need to be more convincing than that.
>  > > > > 
>  > > > > 
>  > > > > 
>  > > > > Unless you went out of your way to change the apache configuration
>  > > > > snippet we ship for apache httpd, then you would seamlessly switch
>  > > > > to
>  > > > > FPM as soon as you installed it and activated the service. And if
>  > > > > you
>  > > > > *did* go out of your way to change it, then you can go change it
>  > 
>  > again
>  > 
>  > > > > to work with PHP-FPM.
>  > > > 
>  > > > My systems never had php-fpm, and certainly didn't get it upon
>  > 
>  > upgrading.
>  > 
>  > > > They've been running just fine for years. I don't see any reason
> to
>  > 
>  > lose
>  > 
>  > > > performance to php-fpm's overhead, and lose the stability of mod_php.
>  > > 
>  > > What are you talking about? In almost every case I've ever seen or
>  > > used, PHP-FPM is *more performant* than mod_php. I work for a company
>  > > that writes an absurd amount of complex PHP software. We switched from
>  > > mod_php to PHP-FPM everywhere *four years ago* for *performance* and
>  > > *stability*. Decoupling the interpreter from the web server improves
>  > > the reliability of the stack and makes it easier for code execution
>  > > and presentation to perform at optimum levels. Moreover, it becomes
>  > > possible to reuse the same FPM instance for multiple applications
>  > > across multiple web servers, which is incredibly useful.
>  > 
>  > Because of FastCGI, php-fpm adds ~1ms to every request, and I'm not the
>  > only
>  > one that's measured similar results. Most systems running a web server
>  > only
>  > run one webserver, generally either just apache or just nginx, so I don't
>  > see
>  > the benefit to that either.
>  
>   https://www.cloudways.com/blog/php-fpm-on-cloud/
>  
>  > > > The only system I have running with php-fpm is one where I installed a
>  > 
>  > PHP
>  > 
>  > > > app which is packaged in Fedora.
>  > > 
>  > > Then just switch everything else. It's not that hard.
>  > 
>  > Why should I have to switch the system that's being used, and potentially
>  > break these servers, just because a package isn't being compiled anymore?
>  > It
>  > still works, and it works very well. It has less overhead than php-fpm,
>  > even!
>  
>  It's not it's the opposite (see above) - you seem to be always opposed to
>  changes in way to not even try to get the benefits of said changes. 
I demonstrated how it adds ~1ms to requests. That's one of the major downsides 
to using FastCGI, and it's unavoidable.

I'm against changes that will be detrimental. You'll notice that, on at least 
one Change proposed for F33, I mentioned that I couldn't see anything wrong 
with it, and didn't think anyone could have any issues with it. That's a +1, 
effectively.

-- 
John M. Harris, Jr.

[Samuel Sieb]

On 7/10/20 10:55 PM, John M. Harris Jr wrote:
>  I demonstrated how it adds ~1ms to requests. That's one of the
> major downsides
>  to using FastCGI, and it's unavoidable. 
You didn't demonstrate anything, you made an unsubstantiated claim.  Did 
you even look at the link that was given?  Regardless of whether or not 
fastcgi adds 1ms to requests, it saves hundreds more elsewhere.  Have 
you even tried it?

[John M. Harris Jr]

On Friday, July 10, 2020 11:45:06 PM MST Samuel Sieb wrote:
>  On 7/10/20 10:55 PM, John M. Harris Jr wrote:
>  
>  > I demonstrated how it adds ~1ms to requests. That's one of the major
>  > downsides to using FastCGI, and it's unavoidable.
>  
>  
>  You didn't demonstrate anything, you made an unsubstantiated claim.  Did 
>  you even look at the link that was given?  Regardless of whether or not 
>  fastcgi adds 1ms to requests, it saves hundreds more elsewhere.  Have 
>  you even tried it? 
I have, and I'm not suggesting anyone change the default back to mod_php. I'm 
suggesting that we don't kill it off while it still works on thousands of 
servers, including servers running F32 right now, and that we don't break 
existing Fedora servers in the upgrade to F33.

It's demonstrably false that php-fpm "saves hundreds" of milliseconds,
unless 
you're counting up every single saved ms over the course of a server's 
runtime. It's not really faster than mod_php, except in cases where opcache is 
used, and you can configure opcache with mod_php as well for similar 
performance gains,

-- 
John M. Harris, Jr.

[Samuel Sieb]

On 7/11/20 1:09 AM, John M. Harris Jr wrote:
>  It's demonstrably false that php-fpm "saves hundreds"
> of milliseconds, unless
>  you're counting up every single saved ms over the course of a server's
>  runtime. It's not really faster than mod_php, except in cases where opcache is
>  used, and you can configure opcache with mod_php as well for similar
>  performance gains, 
Again, did you even look at the linked page?  They did performance 
testing that completely contradicts what you're saying.  What proof do 
you have that php-fpm is not faster than mod_php?  You keep claiming 
that, but haven't provided any evidence.

[John M. Harris Jr]

On Saturday, July 11, 2020 1:34:12 AM MST Samuel Sieb wrote:
>  On 7/11/20 1:09 AM, John M. Harris Jr wrote:
>  
>  > It's demonstrably false that php-fpm "saves hundreds" of
> milliseconds,
>  > unless you're counting up every single saved ms over the course of a
>  > server's runtime. It's not really faster than mod_php, except in cases
>  > where opcache is used, and you can configure opcache with mod_php as well
>  > for similar performance gains,
>  
>  
>  Again, did you even look at the linked page?  They did performance 
>  testing that completely contradicts what you're saying.  What proof do 
>  you have that php-fpm is not faster than mod_php?  You keep claiming 
>  that, but haven't provided any evidence. 
I said that php-fpm was fast than mod_php, however it's just not a huge 
difference. It's not so much faster that it means breaking existing 
configurations to stop shipping a package that still works well, and is still 
widely used.

-- 
John M. Harris, Jr.

[Jonathan Wakely]

On 11/07/20 01:44 -0700, John M. Harris Jr wrote:
> I said that php-fpm was fast than mod_php, however it's just not a
> huge 
When?

I see the opposite claim, repeatedly:

On 10/07/20 18:38 -0700, John M. Harris Jr wrote:
> They've been running just fine for years. I don't see any
> reason to lose
> performance to php-fpm's overhead, and lose the stability of mod_php. 
On 10/07/20 18:49 -0700, John M. Harris Jr wrote:
> still works, and it works very well. It has less overhead than
> php-fpm, even! 
On 11/07/20 01:09 -0700, John M. Harris Jr wrote:
> It's not really faster than mod_php

[John M. Harris Jr]

On Saturday, July 11, 2020 11:47:30 AM MST Jonathan Wakely wrote:
>  On 11/07/20 01:44 -0700, John M. Harris Jr wrote:
>  
>  >I said that php-fpm was fast than mod_php, however it's just not a huge
>  
>  
>  When?
>  
>  I see the opposite claim, repeatedly:
>  
>  On 10/07/20 18:38 -0700, John M. Harris Jr wrote:
>  
>  >They've been running just fine for years. I don't see any reason to lose
>  >performance to php-fpm's overhead, and lose the stability of mod_php.
>  
>  
>  On 10/07/20 18:49 -0700, John M. Harris Jr wrote:
>  
>  >still works, and it works very well. It has less overhead than php-fpm,
>  >even!
>  
>  On 11/07/20 01:09 -0700, John M. Harris Jr wrote:
>  
>  >It's not really faster than mod_php 
php-fpm is marginally faster than mod_php, in some circumstances, when opcache 
is used. However, using php-fpm adds 1ms to every request, as a result of 
using FastCGI.

None of this is relevant to the removal of a package which is still working 
and widely used, however.

-- 
John M. Harris, Jr.

[Gary Buhrmaster]

On Sat, Jul 11, 2020 at 9:11 PM John M. Harris Jr <johnmh(a)splentity.com&gt; wrote:

>  None of this is relevant ... (to) ... a package which is ...
>  widely used, however. 
You keep making that assertion.  Please provide
the audited numbers from a reputable source(*).



(*) Preferably for sites that actually are more than
toys, for which it will takes less time to update the
config then to write an email complaining about the
2 minutes of work any competent admin will have to
do.

[John M. Harris Jr]

On Saturday, July 11, 2020 3:14:06 PM MST Gary Buhrmaster wrote:
>  On Sat, Jul 11, 2020 at 9:11 PM John M. Harris Jr
> <johnmh(a)splentity.com&gt;
>  wrote: 
 
>  
>  > None of this is relevant ... (to) ... a package which is ...
>  > widely used, however.
>  
>  
>  You keep making that assertion.  Please provide
>  the audited numbers from a reputable source(*).
>  
>  
>  
>  (*) Preferably for sites that actually are more than
>  toys, for which it will takes less time to update the
>  config then to write an email complaining about the
>  2 minutes of work any competent admin will have to
>  do. 
There's no reason to "update" any config, php-fpm is just an alternative 
option. mod_php still works well, and doesn't need to be replaced by those 
currently using it. It's still supported by the upstream, is still widely used 
in RHEL, Debian-based systems and so on, and has a few users in Fedora as 
well. It doesn't make sense to drop support for this.

It'd be as simple as accepting ngompa's PR, here:
https://src.fedoraproject.org/rpms/php/pull-request/4

-- 
John M. Harris, Jr.

[Joe Orton]

On Sun, Jul 12, 2020 at 02:27:49PM -0700, John M. Harris Jr wrote:
>  There's no reason to "update" any config, php-fpm is
> just an alternative 
>  option. mod_php still works well, and doesn't need to be replaced by those 
>  currently using it. It's still supported by the upstream, is still widely used 
>  in RHEL, Debian-based systems and so on, and has a few users in Fedora as 
>  well. It doesn't make sense to drop support for this.
>  
>  It'd be as simple as accepting ngompa's PR, here:
>  https://src.fedoraproject.org/rpms/php/pull-request/4 
Remi has rejected the PR.  There is really nothing more to discuss here, 
and I cannot really see you are making a productive contribution to 
technical debate in Fedora by continuing this thread, especially given 
the misinformation which others have already had to correct.

If you are struggling to adapt existing servers from mod_php to php-fpm 
please use the users list to ask for help.

Fedora 33 will not include mod_php - end of story.

Regards, Joe

[Matthew Miller]

On Mon, Jul 13, 2020 at 10:59:24AM +0100, Joe Orton wrote:
>  > It'd be as simple as accepting ngompa's PR, here:
>  > https://src.fedoraproject.org/rpms/php/pull-request/4
>  
>  Remi has rejected the PR.  There is really nothing more to discuss here, 
>  and I cannot really see you are making a productive contribution to 
>  technical debate in Fedora by continuing this thread, especially given 
>  the misinformation which others have already had to correct.
>  
>  If you are struggling to adapt existing servers from mod_php to php-fpm 
>  please use the users list to ask for help.
>  
>  Fedora 33 will not include mod_php - end of story. 
It should be an option to create a "with mod_php" module stream, if anyone
is interested in doing that and keeping up with the maintenance -- fork the
source and apply the patch.


-- 
Matthew Miller
<mattdm(a)fedoraproject.org&gt;
Fedora Project Leader

[John M. Harris Jr]

On Monday, July 13, 2020 2:59:24 AM MST Joe Orton wrote:
>  On Sun, Jul 12, 2020 at 02:27:49PM -0700, John M. Harris Jr wrote:
>  
>  > There's no reason to "update" any config, php-fpm is just an
> alternative 
>  > option. mod_php still works well, and doesn't need to be replaced by those
>  > currently using it. It's still supported by the upstream, is still
>  > widely used in RHEL, Debian-based systems and so on, and has a few users
>  > in Fedora as well. It doesn't make sense to drop support for this.
>  > 
>  > It'd be as simple as accepting ngompa's PR, here:
>  > https://src.fedoraproject.org/rpms/php/pull-request/4
>  
>  
>  Remi has rejected the PR.  There is really nothing more to discuss here, 
>  and I cannot really see you are making a productive contribution to 
>  technical debate in Fedora by continuing this thread, especially given 
>  the misinformation which others have already had to correct. 
What "misinformation" are you referring to?

>  If you are struggling to adapt existing servers from mod_php to
> php-fpm 
>  please use the users list to ask for help. 
I'm not going to be adapting servers from mod_php to php-fpm. mod_php works 
perfectly well, there's no reason to move away from it.

>  Fedora 33 will not include mod_php - end of story. 
That's really a shame, and I don't understand why anyone would choose to 
remove such functionality from Fedora. That really hurts Fedora, more than 
anything else, and it's entirely needless. This patch doesn't hurt the php 
package.

-- 
John M. Harris, Jr.