Summary: PHP should not require Apache, since it may not be used with Apache. Apache-specific bits of PHP should therefore be moved to a sub-package. Problem: Currently php packages require apache. It's an artificial requirement, since PHP does not depend on apache to run, and moreover, sometimes PHP can be used without Apache, for example when it's used with another server such as lighttpd, or in CGI mode with other applications. There are also places that write shell scripts in PHP (regardless whether this is sane or not). Suggestion: So that apache doesn't get installed as dead weight in configurations where PHP is used without it, the bits and pieces of PHP that actually deal with Apache should be moved to a separate sub-package, like mod_php or something similar. Since such a change would likely affect quite a number of existing packages, it should probably be implemented with care.
I think this sounds very reasonble...
I've already been in the exact same situation with lighttpd and php, but never really bothered since although apache gets installed, it's not "on" by default nor does it changee anything. It just takes up more disk space... The drawback of splitting this off, will be the people installing "httpd" and "php" will no longer have a wotking Apache/PHP setup without installing the right little module. Another option would be for php to keep providing the same files and simply remove the apache requirement. Sounds partly ugly, but could lead to less hassles.
Using PHP without Apache httpd is relatively rare, I don't think it's worth messing with the packaging to make this slightly "cleaner". The current packaging does not prevent anything from working, after all. Splitting will mean some kind of compatibility break, and it will increase the binary package bloat since the three SAPI builds compress well into the one package. Marking as WONTFIX, for the time being.
(In reply to comment #3) > Using PHP without Apache httpd is relatively rare, I don't think it's worth > messing with the packaging to make this slightly "cleaner". Dont think so. Maybe for the traditional user base this isn't a useful thing but it's pretty useful for people working on web development. There are various other mainstream distributions which have already done this. Please reconsider this. The compatibility break can be potentially avoided by installing both the newly split up packages on upgrades.
This would also solve some other problems. eAccelerator is in FE (support for php 5.1 is comming soon), this extension only works with mod_php and php-fastcgi but it doesn't with php-cli and php-cgi). Splitting these packages up makes it possible to force this on to the user with depencies.
The only way to ensure that both packages are installed on an upgrade is to have the php package Require the split-out "mod_php" - which would defeat the whole point of the separation. Without that, this is just a massive compatibility break, and there is still not a strong enough case for it. The amount of user confusion would be horrible.
(In reply to comment #6) > The only way to ensure that both packages are installed on an upgrade is to have > the php package Require the split-out "mod_php" - which would defeat the whole > point of the separation. Not true. We can add hacks to Anaconda. > > Without that, this is just a massive compatibility break, and there is still not > a strong enough case for it. The amount of user confusion would be horrible. We can highlight this change in the release announcement and notes to avoid user confusion.
This bug was next on my list to file after bug #187891 but it seems Konstantin beat me to it :) At risk of sounding like "me too", I think this request is extremely reasonable and was indeed my motivation behind filing bug #187891. Increasingly, PHP is being used as a general purpose scripting language as well as with servers other than Apache HTTPD, so it's unfortunate that just to get the CLI environment you have to drag in a whole heap of dependencies including the whole of Apache HTTPD. Personally, I think we should have as separate binary packages: php (or php-cli) php-cgi php-mod_php (or mod_php, or whatever - see bug #187891) Your point about backwards compatibility is a fair one, and one I had (before I knew about this bug :) with a colleague not two hours ago. Hence the importance of getting a Provides: mod_php or whatever into the existing package ASAP - if it had always been there, then the package would be able to be split without hassle. As it stands, some BC problems are inevitable but it's got to be worth it to allow PHP-CLI to work as a standalone environment. Plus, with what Rahul said about an anaconda hack & release notes, it could be made less painful. The company I work for is confident enough about the usefulness (naming conventions notwithstanding) that our internal Fedora/RHEL tree already has already got separate php and php-apache packages (I will clean up and post the specfile patch here shortly). Joe, would you consider re-opening?
*** Bug 191366 has been marked as a duplicate of this bug. ***
*** Bug 191367 has been marked as a duplicate of this bug. ***
*** Bug 191913 has been marked as a duplicate of this bug. ***
See also bug #192196 for a request for at least a dep of php-cli in the core package for apps to Require/Conflict and to facilitate possible future splitting of the packages.
Created attachment 129415 [details] Patch to split mod_php into a separate package As mentioned above, here is a patch against the php-5.1.4 specfile which splits mod_php into a separate package.
(In reply to comment #8) > > Joe, would you consider re-opening? > What's that status anyway? I'm really concerned about not "ever" been a split out of the apache module and the CLI of PHP. These things are the most like to get in the face of all the RedHat and Fedora Core users in Linux meetings (the not having ability to install a program without having to install a hugh amount of dependecies). As I wrote in another report: I needed PHP CLI on my DB server, and now I have a new apache server there, doing nothing. I hope no security expert sees this.
Tim, what's the increase in total binary RPM size with the split-out mod_php subpackage?
w.r.t. comment 14. No, average users are unlikely to care about this issue *at all*. Average users will be using PHP via httpd. Average users will not care or notice that "yum install php" will always pull in httpd too. What *will* impact average users is that when the subpackage split is made, their installation breaks on upgrades. That is why there is resistance to making this change. The extra 3mb (approx - Tim will confirm) of CD/DVD space eaten up by the subpackage is also a user-visible change. So, no, of course, I'm not saying "never", but, my judgement on this is still that the cons outweigh the pros currently.
(In reply to comment #16) > w.r.t. comment 14. No, average users are unlikely to care about this issue *at > all*. Average users will be using PHP via httpd. Average users will not care > or notice that "yum install php" will always pull in httpd too. Thanks for not considering me a average user. :-) Make php = mod_php, and put php-cli in a sepearte package. You can have the common stuff in a php-common package which would be required by any of the two packages (php or php-cli) > What *will* impact average users is that when the subpackage split is made, > their installation breaks on upgrades. That is why there is resistance to > making this change. The extra 3mb (approx - Tim will confirm) of CD/DVD space > eaten up by the subpackage is also a user-visible change. On upgrades, you can install both packages. Rahul said it could be hacked in Anaconda. And by the way, Fedora upgrades never get passed clean. I normally try to backup and do a fresh install. I've seen nasty stuff happen with RH and FC upgrades. > So, no, of course, I'm not saying "never", but, my judgement on this is still > that the cons outweigh the pros currently. My vote is for a reconsideration. I do think that the advantages will be hugh. Many Linux users moved away from RH and won't go to FC because of these kind of dependencies (PHP is not the only case FC has. There are other packages that do the same, but PHP is the one I use most :-))
That actually sounds feasible. We could do: php-common has: /etc/php.ini, /etc/php.d, libdir/php/modules, docdir, mandir, /var/lib php has: libphp5.so, conf.d/php.conf php-cli has: bindir/php* php can require php-cli so upgrades never lose anything, and by default "yum install php" DTRT, and you guys who want to get rid of the httpd deps can install just php-cli and php-common. Would that sound reasonable to everyone, have I missed anything?
(and both php/php-cli both require php-common of course)
(In reply to comment #18) > php has: > libphp5.so, conf.d/php.conf > > php-cli has: > bindir/php* would the php-cli use the same php.ini as libphp? It's good for me, but maybe someone wants to change memory management, etc. from on to another > php can require php-cli so upgrades never lose anything, and by default "yum > install php" DTRT, and you guys who want to get rid of the httpd deps can > install just php-cli and php-common. > > Would that sound reasonable to everyone, have I missed anything? It's reasonable enough. With that, I could have my DB server with PHP, but not httpd. Is this going to be available on FC6 or earlier? I think it would be better to let it wait for FC6.
I would vote for introducing this to FC5 since it will not change backwards compatability nor dos it change any aspect of its use. Separate php.ini files (if wanted) would have to wait for FC6 in any case. This would be a big plus for installs from respins too. Btw, I use php console scripts a lot. Both on my workstation and all other (~75) servers I administer. Having apache installed on all of these when not needed is a pretty big maintenance load since those too need to be upgraded to latest versions even though never used.
This is not happening for FC5, FC6 at earliest.
Please note that pear needs php-cli to function and php without pear isn't very usefull.
File sizes from my build yesterday: 1.3M mod_php-5.1.4-1.i386.rpm 2.4M php-5.1.4-1.i386.rpm 29K php-bcmath-5.1.4-1.i386.rpm 36K php-dba-5.1.4-1.i386.rpm 12M php-debuginfo-5.1.4-1.i386.rpm 511K php-devel-5.1.4-1.i386.rpm 108K php-gd-5.1.4-1.i386.rpm 49K php-imap-5.1.4-1.i386.rpm 31K php-ldap-5.1.4-1.i386.rpm 963K php-mbstring-5.1.4-1.i386.rpm 81K php-mysql-5.1.4-1.i386.rpm 36K php-ncurses-5.1.4-1.i386.rpm 49K php-odbc-5.1.4-1.i386.rpm 60K php-pdo-5.1.4-1.i386.rpm 64K php-pgsql-5.1.4-1.i386.rpm 25K php-snmp-5.1.4-1.i386.rpm 128K php-soap-5.1.4-1.i386.rpm 92K php-xml-5.1.4-1.i386.rpm 52K php-xmlrpc-5.1.4-1.i386.rpm
(In reply to comment #23) > Please note that pear needs php-cli to function and php without pear isn't very > usefull. Joe said there would be a requierment of php-cli when installing the apache php module (called php I think). And php-pear would also need the php-cli requirement (no need for an explicit requirement of php or php-cli), which in the case of a web server with php, would already be satisfied.
(In reply to comment #18) > php-common has: > /etc/php.ini, /etc/php.d, libdir/php/modules, docdir, mandir, /var/lib > php has: > libphp5.so, conf.d/php.conf > php-cli has: > bindir/php* > php can require php-cli so upgrades never lose anything, and by default "yum > install php" DTRT, and you guys who want to get rid of the httpd deps can > install just php-cli and php-common. > > Would that sound reasonable to everyone, have I missed anything? Sounds sensible to me, with the possible exception that php-cgi should perhaps not be in the CLI package (separate php-cgi?) In reply to comment #20: > would the php-cli use the same php.ini as libphp? It's good for me, but maybe > someone wants to change memory management, etc. from on to another It's worth noting that PHP has an in-built way of handling this. php-cli.ini, if it exists, is used in preference to php.ini for CLI PHP. (I think this holds true for other SAPIs, too). Bear in mind also that a number of default options are different for the CLI SAPI (see http://www.php.net/manual/en/features.commandline.php for details).
OK, thanks for all the feedback. php-5.1.4-6 is in Raw Hide now and has the -common/-cli split which should hopefully satisfy the requirements here. (I did not bother further splitting out -cgi)
Small mistake : You forgot to add a %defattr line to both the -common and -cli sub-packages ;-) I noticed after rebuilding PHP 5 for RHEL4 and getting files owned by my build user.
Reopening because of another missing change : All of the module sub-packages built from the php source packages (php-pgsql, php-imap, php-mysql etc.) still require "php", so if you only install "php-cli", fine, httpd isn't pulled in, but as soon as you need one of those modules... you get httpd again. Maybe just changing all of : Requires: php = %{version}-%{release} To : Requires: php-common = %{version}-%{release} (except for php-devel) Would be enough? One could install "php-imap" and not get either the CLI php nor the apache module with this change, though... so maybe require something new, provided by both "php" and "php-cli" packages would be best? But then in this last example, I'm not sure how yum would decide between "php" and "php-cli" to fullfill the dependency when needed. Thoughts?
Can someone give me a good reason of why someone would install, for example, php-imap and not one of apache php or php CLI? It's plainly ignorance, and it's imposible to cover up for every ignorant act that a programmer or system administrator can do (I don't see a normal desktop user installing a webserver or php-cli to run his scripts). I think all these modules should require php-common. P.D.: Anybody in the rpm team thought about adding suggestions in the rpm instalation, the the debian packages have? That would solve the problem here.
So, Joe? Does changing the dependency of all the sub-packages from "php = version-release" to "php-common = version-release" seem okay to you? Seems somewhat late for FC6, but if it could go in it would be really great!
Yes, absolutely. I'll do it for the first update. (didn't want to make any substantial changes this close to FC6)
Hey Joe, I see you've been busy with 5.2.0 for devel recently, but still haven't made that change. Could you do it quickly soon so that we get this over with once and for all? Thanks! :-)
php-5.1.6-3.2.fc6 has been pushed to FC6 updates-testing, which should contain the fix for this bug. You can test the new packages by running: # yum --enablerepo=updates-testing update php
*** Bug 232925 has been marked as a duplicate of this bug. ***