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-packages/ [1] https://bugzilla.redhat.com/show_bug.cgi?id=1290267 [2] https://docs.fedoraproject.org/en-US/packaging-guidelines/Naming/#_httpd_pam_and_sdl On Wed, Jun 3, 2020 at 1:00 AM Peter Pentchev <roam@xxxxxxxxxxx> 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@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 > _______________________________________________ > 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 -- Carl George _______________________________________________ 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
