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@xxxxxxxxxxx roam@xxxxxxxxxx pp@xxxxxxxxxxxx
PGP key: http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
