Bug 1290267 - RFE: move mod_php to a subpackage
Summary: RFE: move mod_php to a subpackage
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: php
Version: rawhide
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Remi Collet
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-12-09 23:59 UTC by Carl George
Modified: 2017-05-17 13:56 UTC (History)
9 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-05-17 13:56:38 UTC


Attachments (Terms of Use)

Description Carl George 2015-12-09 23:59:59 UTC
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.  Most other Apache HTTP Server modules in Fedora follow the mod_* naming structure.  Most other languages packages in Fedora are just the name of the language.  The purpose of the packages isn't completely clear from just the package names.  These inconsistencies causes confusion for end users.  Other distributions name their mod_php packages descriptively enough to avoid this problem.

- Debian/Ubuntu: libapache2-mod-php5
- OpenSUSE: apache2-mod_php5
- Arch: php-apache

I believe we can improve this situation by moving mod_php to its own subpackage.  Legacy compatibility can be maintained by adding a "php" virtual provides to the mod_php subpackage; users that run `yum install php` would see that it actually resolves to mod_php.  The top level package (spec file and source RPM) name would still be named php, but would not result in a php package when built.

I created a mirror [1] of the package source git repository [2] to test the actual implementation of this.  The changes are in commit 0403280 [3] of the "tweak" branch".  Bootstrap builds complete successfully locally in mock.

[1]: https://github.com/carlwgeorge/php
[2]: http://pkgs.fedoraproject.org/cgit/php.git
[3]: https://github.com/carlwgeorge/php/commit/0403280

Comment 1 Neal Gompa 2015-12-10 00:54:02 UTC
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.

Comment 2 Remi Collet 2015-12-10 07:19:20 UTC
> 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"

Comment 3 Remi Collet 2015-12-10 12:37:48 UTC
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.

Comment 4 Joe Orton 2015-12-10 12:38:48 UTC
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.

Comment 5 Joe Orton 2015-12-10 12:42:21 UTC
+1 on comment 3.

Comment 6 Carl George 2015-12-10 15:33:12 UTC
> 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.

Comment 7 Carl George 2015-12-10 19:13:55 UTC
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...

Comment 8 Neal Gompa 2015-12-11 04:15:32 UTC
@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

Comment 9 Carl George 2015-12-11 14:19:31 UTC
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.

Comment 10 Neal Gompa 2015-12-13 05:56:40 UTC
@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.

Comment 11 Remi Collet 2015-12-13 08:04:42 UTC
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)

Comment 12 Neal Gompa 2015-12-14 05:26:15 UTC
@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.

Comment 13 Remi Collet 2015-12-19 07:17:41 UTC
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).

Comment 14 Carl George 2015-12-20 04:07:01 UTC
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.

Comment 15 Steven Barre 2015-12-29 04:23:20 UTC
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.

Comment 16 Neal Gompa 2016-12-14 11:29:16 UTC
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?

Comment 17 Remi Collet 2016-12-14 13:05:59 UTC
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.

Comment 18 Carl George 2016-12-14 13:23:04 UTC
> 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.

Comment 19 Remi Collet 2016-12-14 13:29:07 UTC
To be clear, move from "DEFERRED" to "WONTFIX"

Comment 20 Brandon Tomlinson 2016-12-14 16:58:14 UTC
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

Comment 21 Neal Gompa 2017-05-17 11:04:32 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.