Bug 177821 - PHP shouldn't require httpd
PHP shouldn't require httpd
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: php (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Joe Orton
David Lawrence
: Reopened
: 191366 191367 191913 232925 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-01-14 17:07 EST by Konstantin Ryabitsev
Modified: 2007-11-30 17:11 EST (History)
10 users (show)

See Also:
Fixed In Version: 5.1.6-3.3.fc6
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-01-31 12:41:35 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Patch to split mod_php into a separate package (2.83 KB, patch)
2006-05-18 08:20 EDT, Tim Jackson
no flags Details | Diff

  None (edit)
Description Konstantin Ryabitsev 2006-01-14 17:07:59 EST
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.
Comment 1 Thomas M Steenholdt 2006-01-15 16:40:41 EST
I think this sounds very reasonble... 
Comment 2 Matthias Saou 2006-01-16 05:35:13 EST
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.
Comment 3 Joe Orton 2006-01-16 05:42:40 EST
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.
Comment 4 Rahul Sundaram 2006-03-24 13:21:23 EST
(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.
Comment 5 Bart Vanbrabant 2006-03-25 02:35:50 EST
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.
Comment 6 Joe Orton 2006-03-27 06:07:13 EST
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.
Comment 7 Rahul Sundaram 2006-03-28 07:44:37 EST
(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.

Comment 8 Tim Jackson 2006-04-04 10:06:02 EDT
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?
Comment 9 Joe Orton 2006-05-11 08:57:50 EDT
*** Bug 191366 has been marked as a duplicate of this bug. ***
Comment 10 Joe Orton 2006-05-11 08:58:32 EDT
*** Bug 191367 has been marked as a duplicate of this bug. ***
Comment 11 Joe Orton 2006-05-16 09:37:30 EDT
*** Bug 191913 has been marked as a duplicate of this bug. ***
Comment 12 Tim Jackson 2006-05-18 06:45:20 EDT
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.
Comment 13 Tim Jackson 2006-05-18 08:20:14 EDT
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.
Comment 14 Martí­n Marqués 2006-05-18 08:45:06 EDT
(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.
Comment 15 Joe Orton 2006-05-18 09:05:20 EDT
Tim, what's the increase in total binary RPM size with the split-out mod_php
subpackage?
Comment 16 Joe Orton 2006-05-18 09:21:32 EDT
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.
Comment 17 Martí­n Marqués 2006-05-18 10:30:33 EDT
(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 :-))
Comment 18 Joe Orton 2006-05-18 10:52:16 EDT
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?
Comment 19 Joe Orton 2006-05-18 10:57:13 EDT
(and both php/php-cli both require php-common of course)
Comment 20 Martí­n Marqués 2006-05-18 13:08:00 EDT
(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.
Comment 21 Hans Kristian Rosbach 2006-05-19 03:31:38 EDT
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.
Comment 22 Joe Orton 2006-05-19 04:50:01 EDT
This is not happening for FC5, FC6 at earliest.
Comment 23 Bart Vanbrabant 2006-05-19 06:33:41 EDT
Please note that pear needs php-cli to function and php without pear isn't very
usefull.
Comment 24 Tim Jackson 2006-05-19 07:07:25 EDT
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
Comment 25 Martí­n Marqués 2006-05-19 08:49:08 EDT
(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.
Comment 26 Tim Jackson 2006-05-28 16:57:35 EDT
(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).
Comment 27 Joe Orton 2006-06-07 08:36:03 EDT
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)
Comment 28 Matthias Saou 2006-06-08 13:50:30 EDT
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.
Comment 29 Matthias Saou 2006-09-21 07:45:25 EDT
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?
Comment 30 Martí­n Marqués 2006-09-21 08:08:48 EDT
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.
Comment 31 Matthias Saou 2006-10-02 15:10:49 EDT
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!
Comment 32 Joe Orton 2006-10-05 10:00:00 EDT
Yes, absolutely.  I'll do it for the first update.  (didn't want to make any
substantial changes this close to FC6)
Comment 33 Matthias Saou 2006-11-16 07:05:18 EST
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! :-)
Comment 34 Joe Orton 2006-11-27 11:34:27 EST
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

Comment 35 Joe Orton 2007-03-19 11:01:07 EDT
*** Bug 232925 has been marked as a duplicate of this bug. ***

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