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