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

2020-07-13 Thread 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.

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org


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

2020-07-13 Thread 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

Fedora Project Leader
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org


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

2020-07-13 Thread 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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org


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

2020-07-12 Thread 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 
> 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.

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org


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

2020-07-11 Thread Gary Buhrmaster
On Sat, Jul 11, 2020 at 9:11 PM John M. Harris Jr  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.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org


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

2020-07-11 Thread 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.

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org


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

2020-07-11 Thread 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

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org


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

2020-07-11 Thread 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.

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org


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

2020-07-11 Thread 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.

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org


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

2020-07-11 Thread 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.

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org


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

2020-07-11 Thread 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?

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org


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

2020-07-10 Thread 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  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 
> > > 
> > > 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
> > > > > 
> > > > > 
> > > > > 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
> > > > > > > 
> > > > > > > 
> > > > > > > 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
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > 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)
> > > > > > > > > > 

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

2020-07-10 Thread 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 
> 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
> > > 
> > > 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.

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org


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

2020-07-10 Thread drago01
On Saturday, July 11, 2020, John M. Harris Jr  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 
> > 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
> > > > 
> > > > 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
> > > > > > 
> > > > > > 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
> > > > > > > > 
> > > > > > > > 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)
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > 

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

2020-07-10 Thread Neal Gompa
On Fri, Jul 10, 2020 at 10:05 PM John M. Harris Jr  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 
> > 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!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org


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

2020-07-10 Thread 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 
> 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.

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org


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

2020-07-10 Thread Gary Buhrmaster
On Sat, Jul 11, 2020 at 1:50 AM John M. Harris Jr  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.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org


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

2020-07-10 Thread 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 
> 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
> > > 
> > > 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
> > > > > 
> > > > > 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
> > > > > > > 
> > > > > > > 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)
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > 

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

2020-07-10 Thread Neal Gompa
On Fri, Jul 10, 2020 at 9:38 PM John M. Harris Jr  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 
> > 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
> > > > 
> > > > 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
> > > > > > 
> > > > > > 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)
> > > > > > 

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

2020-07-10 Thread 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 
> 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
> > > 
> > > 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
> > > > > 
> > > > > 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
> > > > > > >
> > > > > > >
> > > > > > >
> 

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

2020-07-10 Thread Neal Gompa
On Fri, Jul 10, 2020 at 9:26 PM John M. Harris Jr  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 
> > 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
> > > > 
> > > > 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 

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

2020-07-10 Thread 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 
> 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
> > > 
> > > 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 

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

2020-07-10 Thread Neal Gompa
On Fri, Jul 10, 2020 at 8:59 PM John M. Harris Jr  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 
> > wrote:
> > >
> > >
> > > On Thursday, May 28, 2020 12:53:26 PM MST Ben Cotton wrote:
> > >
> > > > https://fedoraproject.org/wiki/Changes/drop_mod_php
> > > >
> > > >
> > > >
> > > > == Summary ==
> > > > mod_php (apache2handler) is an optional httpd module to execute PHP
> > > > scripts, not used.
> > > >
> > > >
> > > >
> > > > == Owner ==
> > > > * Name: [[User:Remi| Remi Collet]]
> > > > * Email: remi at fedoraproject dot org
> > > >
> > > >
> > > >
> > > >
> > > > == Detailed Description ==
> > > > By default php-fpm is used for a few versions. mod_php is not
> > > > supported for threaded modules. mod_php usage also increases security
> > > > risk, sharing the same process than httpd.
> > > >
> > > >
> > > >
> > > > Drop mod_php from php build. This will only affect user of httpd in
> > > > "prefork" mode, which will also use php-fpm.
> > > >
> > > >
> > > >
> > > > php-fpm is already used but most users of httpd and nginx without any
> > > > issue.
> > >
> > >
> > >
> > > > The "php" package will be kept as a metapackage, installing (weak
> > > > dependencies) most commonly used extension, thus reducing the
> > > > difference between "yum install php" (flat repository) and "yum module
> > > > install php" (modular repository).
> > > >
> > > >
> > > >
> > > > == Benefit to Fedora ==
> > > >
> > > >
> > > >
> > > > Only provide the modern way to execute PHP in a web server.
> > > >
> > > >
> > > >
> > > > == Scope ==
> > > >
> > > >
> > > >
> > > > PHP rebuild (mod_php build is already conditional)
> > > >
> > > >
> > > >
> > > > * Other developers: N/A (not a System Wide Change)
> > > > * Release engineering:  N/A
> > > > * Policies and guidelines: N/A (not a System Wide Change)
> > > > * Trademark approval: N/A (not needed for this Change)
> > > >
> > > >
> > > >
> > > >
> > > > == Upgrade/compatibility impact ==
> > > > N/A (not a System Wide Change)
> > > >
> > > >
> > > >
> > > > == How To Test ==
> > > >
> > > >
> > > >
> > > > * install and play with your web applications
> > > >
> > > >
> > > >
> > > > == User Experience ==
> > > >
> > > >
> > > >
> > > > No change.
> > > >
> > > >
> > > >
> > > >
> > > > == Dependencies ==
> > > >
> > > >
> > > >
> > > > None (dependency on "php" is already forbidden by Guidelines)
> > > >
> > > >
> > > >
> > > > == Contingency Plan ==
> > > > * revert
> > > >
> > > >
> > > >
> > > > * Contingency deadline: N/A (not a System Wide Change)
> > > > * Blocks release? N/A (not a System Wide Change), Yes/No
> > > > * Blocks product? product
> > > >
> > > >
> > > >
> > > > == Documentation ==
> > >
> > >
> > >
> > > Now that this has been accepted, I take it that the current maintainer of
> > > mod_php no longer wants to maintain it? I'd like to offer to take over
> > > the
> > > package if that's the case, so that Fedora will continue to work for
> > > those
> > > using mod_php.
> >
> >
> > mod_php is built from the php source tree, so no, you can't really do that.
>
> In that case, is it possible that it can just be kept in the build, so that we
> can continue to support it? There's really not a whole lot of reason to kill
> off something as useful and widely used as mod_php while it's still working
> well for thousands, if not hundreds of thousands, of servers, and is still the
> preferred backend for Apache, which even defaults to prefork upstream.
>

Fedora has not defaulted to prefork for Apache httpd since Fedora 27,
upstream Apache httpd has not defaulted to it for even *longer*.

Apache httpd switched to event mpm by default more than a decade ago
(at least 12 years ago, from what I can tell, most likely longer!).
Fedora finally followed upstream on this in Fedora 27, and mod_php has
been broken in the default configuration since then.

But even with that, we've had PHP-FPM as the default with Apache httpd
for five years now. Out of the box, that's what is set up. Nobody
noticed that mod_php was broken for the past two years, and nobody has
had any real issues with the default PHP SAPI being switched five
years ago.

At this point, the only reason to keep it is if there's something that
somehow absolutely cannot run with PHP-FPM but can with mod_php. If
something like that is the case, we *could* restore it as a
subpackage. But it'd have to be a pretty compelling case...




--
真実はいつも一つ!/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org


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

2020-07-10 Thread 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 
> 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.

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org


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

2020-07-10 Thread Neal Gompa
On Fri, Jul 10, 2020 at 8:55 PM John M. Harris Jr  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!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org


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

2020-07-10 Thread 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.

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org


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

2020-06-04 Thread 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.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org


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

2020-06-04 Thread 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-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  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 

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

2020-06-02 Thread 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  r...@ringlet.net r...@debian.org p...@storpool.com
PGP key:http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint 2EE7 A7A5 17FC 124C F115  C354 651E EFB0 2527 DF13


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org


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

2020-06-02 Thread 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.

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org


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

2020-06-02 Thread 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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org


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

2020-06-01 Thread 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

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org


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

2020-05-30 Thread Alexander Ploumistos
On Sat, May 30, 2020 at 11:14 AM 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...

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.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org


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

2020-05-30 Thread 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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org


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

2020-05-29 Thread 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

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org


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

2020-05-29 Thread 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@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
- -- 
Igor Raits 
-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-
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org


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

2020-05-29 Thread Neal Gompa
On Fri, May 29, 2020 at 4:01 AM 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.
>

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!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org


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

2020-05-29 Thread 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

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org


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

2020-05-29 Thread 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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org


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

2020-05-28 Thread 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

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org