Bug 1290267

I would suggest instead of a virtual Provides to just make it the new php-common and add a "Recommends: mod_php" or whatever to ensure that DNF pulls it in without making it a hard requirement. That allows for a seamless transition and should make the httpd module optional.

Additionally, I would suggest that we merge php-cli into the main php package, since that's more consistent with our other language packages, where the interpreter is present in the base package. SUSE does this, but Debian/Ubuntu does not. Of course, this is not required.

We could also take advantage of rich dependencies to select the correct thing to install based on what webserver you're using in the Recommends field. For example, "Recommends: (mod_php if httpd-filesystem)" and "Recommends: (php-fpm if nginx-filesystem)" could be used to ensure the correct version is installed based on which webserver is installed.

> Additionally, I would suggest that we merge php-cli into the main php package.

Yes.
(and "php" already pull "php-cli")

> We could also take advantage of rich dependencies to select the correct thing to install based on what webserver you're using in the Recommends field. For example, "Recommends: (mod_php if httpd-filesystem)" and "Recommends: (php-fpm if nginx-filesystem)" could be used to ensure the correct version is installed based on which webserver is installed.

No.

You can use apache/nginx without PHP (static site or other languages)

"filesystem" package have been split to allow webapp to drop their configuration without having to require the full packages (see phpMyAdmin).

PHP Webapp have to require "mod_php" or better php(httpd), provided by both mod_php and fpm.

More apache works now perfectly with "php-fpm" (mod_php will have to die in the future).

So a better requirement is (rich dep.)
Requires (httpd & mod_php) | (httpd & php-fpm) & (nginx + php-fpm)

> Currently Fedora ships mod_php (the PHP module for the Apache HTTP Server) as the "php" package.  The "php-common" subpackage is actually the PHP language itself.  This is inconsistent with other Fedora packages.

Yes, bad name.... but history.
Notice "php-common" is mostly empty (no sapi)

Pros: it will be less confusing for "new" users and will avoid having mod_php installed in most case (yum install php)

Cons: it will be very confusing for "old" users, as this name is used for >15 years.

So, I don't have strong opinion about this proposal.

In all case, this probably need to be made a "system wide feature"

Alternative idea, make "php" an empty meta-package with soft dependency on all SAPI, e.g.

Requires:   php-cli
Recommends: php-fpm
Suggest:    mod_php
Suggest:    php-dbg

This way , the classical "dnf/yum install httpd php" will still result in a usable web server, out of the box, encouraging people to switch to fpm instead of mod_php.

And probably better to differ any change to PHP 7.

I think the "libapache*" names for httpd modules used by Debian are a great example of design by committee producing pedantically correct & consistent but perfectly awful package names, so I don't find the appeal to consistency at all compelling.   "libapache" is a totally confusing and meaningless thing to the entire world outside of Debian hackers.  Rant aside...

Principle of least surprise: "dnf install php" should do the right thing, and for the vast majority of users that will mean make httpd support php.  The typical use-case of php in Fedora is different to the typical use-case of perl or python, so it's fine having the default behaviour a bit different.

I'm strongly against making "yum install php" not make httpd support php - whether that is via FPM or mod_php.  I think I'm fine with making a weak dependency on php-cli from php... not sure about hint/very weak.

+1 on comment 3.

> Cons: it will be very confusing for "old" users, as this name is used for >15 years.

I understand that major changes should be carefully considered.  However, "we've always done it this way" is not a valid standalone reason, and should not stand in the way of improvement.

> And probably better to differ any change to PHP 7.

+1 to this.

> I think the "libapache*" names for httpd modules used by Debian are a great example of design by committee producing pedantically correct & consistent but perfectly awful package names, so I don't find the appeal to consistency at all compelling.   "libapache" is a totally confusing and meaningless thing to the entire world outside of Debian hackers.  Rant aside...

Allow me to clarify.  I want more consistency within Fedora for httpd module naming, not consistency with another distro's package names.  I merely brought up the other distro package names to point out that they choose more descriptive names.  I'm certainly not suggesting using the "libapache" name anywhere in Fedora.

+1 on comment 3 from me as well.

One more thought crossed my mind.  A seamless upgrade experience for rawhide and fedup would require that mod_php obsolete php.  That won't work if we want to use php as a meta-package.  Would it be beneficial to split this process into stages?

stage 1: create the mod_php subpackage with a virtual provides for php
stage 2: remove the virtual provides for php from mod_php
stage 3: re-introduce the php package as an empty meta-package with weak dependencies

Separating these steps out over time would theoretically allow a smoother experience for some users.  However, there are times when you just need to rip the band-aid off...

@Carl:

I don't think it would make sense at all for "php" to be a virtual package, ever. And going from real -> virtual -> real is unnecessary, especially when smart resolvers can handle the shuffling a bit better.

You could jump straight to stage 3 and I expect it to work fairly seamlessly. As long as the weak dependencies are set up as Recommends rather than Suggests, it should work fine.

@Remi:

The rich dependency conditional is inverted from how it's normally understood, AFAICT[0].

It sounds like what you're asking for is the following:

Recommends: (((mod_php or php-fpm) if httpd) or (php-fpm if nginx))

This declaration indicates a "strong" weak forward dependency that is expressed as such: "Recommend either mod_php OR php-fpm IF httpd is installed OR php-fpm IF nginx is installed."

@Joe:

Personally, I don't like the contortions that Debian does to their package names. That said, I don't think that "mod_<name>" itself is necessarily clear what it is. Regardless, I merely ask that we actually follow the *other* Fedora httpd modules in naming for the php module, rather than having this weird exception with no real reason today.

[0]: http://rpm.org/wiki/PackagerDocs/BooleanDependencies

Hey Neal,

For it to work like that, the new php package would have to Recommend mod_php.  Would it also Recommend php-fpm?  That would cause `dnf install php` to install both SAPIs.  Remi proposed that it Recommend php-fpm and only Suggest mod_php.  I'm just not seeing how this all lines up without having mod_php Obsolete php temporarily.  Additionally, I'm concerned that trying to hammer out the details of a meta-package will stall this proposal out.  The main thing I care about is the php->mod_php transition.  If we accomplish just that in one Fedora release cycle, we can look at the meta-package goal for the next Fedora release cycle, and users that are fedup-ing through releases would have a smooth transition.

@Carl:

The Recommends line I mentioned in comment 8 would select the correct one based on which server you have installed. If I remember correctly, it also resolves it left-first in libsolv, which would mean that if neither mod_php nor php-fpm are installed, it'll install mod_php. 

Alternatively, you could have it recommend mod_php initially, and then switch it to Suggests along with php-fpm being switched to Recommends. I believe that would avoid the Obsoleting problem.

The annoying issue with adding Obsoletes/Provides is that they have to stick around for N+2 releases, in order to enable upgrading from an unsupported release to any given supported one. They'd probably stick around longer "just because", too.

As this will occurs in a major update (new fedora version, new php version), we will only recommends php-fpm (which works out of the box with apache and nginx). mod_php should die.

So "dnf install php" will result, as in previous version, to both cli and webserver SAPI.

For people upgrading from older fedora version, we will (probably) obsolete "php < 7" (in mod_php)

@Remi:

Does this mean that we could see this rearchitecting occur as part of a push to PHP 7 for F24?

If it is true that php-fpm will "just work" out of the box on nginx and httpd when installed, then I don't see why this problem is so complex. We could just go ahead and use "Recommends: php-fpm" and leave mod_php out of the equation.

I do still think that php-common and php-cli should probably be merged into the main php package, but it's not strictly necessary, I suppose.

After more thinking, I don't see this as really usefull, so not a priority.
"dnf search/install mod_php" works as expected.

We have this bad named since ever. And there are still tons of packages which still requires "php" (probably badly).

A php meta-package may not be really useful, but moving mod_php into a subpackage still has value.  The current naming scheme is confusing for both new an old users.  I feel like this proposal got derailed by the meta-package idea, so let's refocus on the original proposal.

- move php (mod_php) files into a mod_php subpackage
- mod_php provides php
- mod_php obsoletes php < 7

With that change, the following commands will work as expected.

- dnf search mod_php
- dnf search php
- dnf install mod_php
- dnf install php

Packages requiring "php" will continue to work just fine because of the virtual provides.  Users upgrading between releases will see the php package smoothly replaced by the mod_php package.

I don't see any drawbacks here.  As Grace Hopper said, "we've always done it this way" is a dangerous phrase.  A mod_php package would be more descriptive and more consistent.  Please reconsider this proposal so we can make Fedora better.

I agree with @Carl and would like to see the PHP packages more consistent with other language packages. Having a package named php-cli is silly.

I don't think that having it called php-cli is necessarily bad, but definitely leaving mod_php as the "php" package is.

@Remi, would you consider renaming php to mod_php for Fedora 26?

No, as mod_php is not Guidelines compliant, and mod_* packages only exist for "history" ("we've always done it this way")

Current name could be "php-apache2handler" or "httpd-php', definitively, not something I want to work on.

> mod_php is not Guidelines compliant

You are incorrect.  "mod_php" would be compliant; it's the current name of "php" that is not compliant.

https://fedoraproject.org/wiki/Packaging:Naming?rd=Packaging:NamingGuidelines#httpd.2C_pam.2C_and_SDL

> Apache httpd addons use the format: mod_%{child}, with an underscore "_" as a delimiter.

To be clear, move from "DEFERRED" to "WONTFIX"

Hmm Remi I think you miss Carlos' response about name compliance!

So wait, if I have nginx install on my box and I installed php will it make nginx work with a php module????

-out, Brandon

Coming back to this with a better understanding of how rich dependencies can work (as allowed in Fedora currently), I propose the following:

php turned into a metapackage. It pulls php-cli as a requirement.

mod_php subpackage requires httpd and has a rich dep "Supplements: (php%{?_isa} and httpd%{?_isa})".

But if we want to ignore metapackage stuff, I'd settle for just having the php package renamed to mod_php, as stated in comment 14.

Can we please revisit this and do this like Carl suggests in the description? Or maybe something like what I have proposed?

The current layout has caused *numerous* problems with users and I continually field complaints and confusion over the packaging.

I'd be happy to make a pull request with a proposal (in fact I have one ready to go based on my downstream work on the PHP stack).

I still don't see what are the "numerous" problems.

BTW, the plan is

- keep "php" a metapackage (to reduce the gap between "yum install php" and "yum module install php")
- kill mod_php (which is already no more used)

Since https://src.fedoraproject.org/rpms/php/c/e2e7a334d0e0f9d9f1703e7dc85204fe61414904?branch=master
mod_php buils is now optional.

So all the needed change is

 %global with_modphp   0


So closing this one, there is no plan to create a new "mod_php" package, as the plan is really to drop this module.