Bug 173804 - Core PHP RPM does not have Provides for built-in modules/extensions
Summary: Core PHP RPM does not have Provides for built-in modules/extensions
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: php
Version: 4
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Joe Orton
QA Contact: David Lawrence
URL:
Whiteboard:
Depends On:
Blocks: 176725
TreeView+ depends on / blocked
 
Reported: 2005-11-21 14:20 UTC by Tim Jackson
Modified: 2007-11-30 22:11 UTC (History)
2 users (show)

Fixed In Version: 5.1.2-5
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2006-02-28 17:09:09 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
patch against rawhide to add Provides to the core PHP package (773 bytes, patch)
2005-11-23 14:02 UTC, Tim Jackson
no flags Details | Diff

Description Tim Jackson 2005-11-21 14:20:37 UTC
Description of problem:
The PHP core RPM package (php-x.y.z) does not Provide any resources related to
its built-in extensions which other packages can use to depend on.

Many extensions to PHP (IMAP, LDAP etc.) are built as subpackages (php-imap,
php-ldap etc.) which is great, and other packages can Require: php-imap etc. if
they need that functionality. However, there are also many extensions (e.g.
exif, dba, dbx etc.) which are build-time optional and treated by PHP as
separate "modules" but packaged internally within the main PHP RPM. This is not
a problem in itself, but for consistency the main PHP RPM should then include
appropriate Provides: e.g. Provides: php-exif, php-dba etc. (or should that be
php(exif), php(dba)?) so that other packages can depend on it. 

This is particularly significant for PEAR packages; the PEAR dependency
mechanism provides a means by which PEAR packages can declare dependencies on
various modules of PHP, and many (rightly) do declare dependencies on modules
which are part of the core package.  Without a consistent scheme for having RPM
dependencies which PEAR package RPMs can depend on, RPM spec files for PEAR
packages can't be auto-generated with appropriate dependencies. (NB the current
packaged version of PEAR doesn't support generation of RPM dependencies with
"pear makerpm", but this has been fixed upstream - see
http://pear.php.net/bugs/bug.php?id=1870 - although upstream still only builds
in deps for other PEAR packages, not for PHP modules. However, fixing this bug
would allow "pear makerpm" to generate specs with more complete dependency lists)


Version-Release number of selected component (if applicable):
php-5.0.4-10.5

Steps to Reproduce:
1. rpm -q --provides php
  
Actual results:
config(php) = 5.0.4-10.5
libphp5.so
php = 5.0.4-10.5


Expected results:
config(php) = 5.0.4-10.5
libphp5.so
php = 5.0.4-10.5
php-exif = 5.0.4-10.5
php-dba = 5.0.4-10.5
php-dbx = 5.0.4-10.5
etc.

Comment 1 Tim Jackson 2005-11-23 13:40:07 UTC
Complete list of built-in modules/extensions included in the php-5.0.4-10.5 package:

bz2
calendar
ctype
curl
dbx
dio
exif
ftp
gettext
gmp
iconv
libxml
mime_magic
openssl
pcntl
pcre
posix
pspell
session
shmop
SimpleXML
sockets
SPL
?standard (probably not necessary to include in Provides)
sysvsem
sysvshm
sysvmsg
tokenizer
wddx
xml
yp
zlib

Comment 2 Tim Jackson 2005-11-23 14:02:32 UTC
Created attachment 121396 [details]
patch against rawhide to add Provides to the core PHP package

php-xml is omitted; this is in a separate package. Not sure why phpinfo()
reports the "xml" module as existent when the php-xml package is not installed.

Comment 3 Tim Jackson 2005-11-23 17:27:20 UTC
A nice side-effect of this will be that if any of the currently-built-in modules
are ever split out into sub-packages, a "yum upgrade" or similar should pull in
the new package necessary to maintain the same functionality.

Comment 4 Tim Jackson 2006-01-12 15:41:33 UTC
If it would be possible to get this into FC5 it would be great.
By the way, I just found out the easy way of getting the compiled-in module list:

php -m


Comment 5 Joe Orton 2006-02-28 17:09:09 UTC
I've added this, but following my "make up an arbitrary convention as you go
along" convention:

- all extension modules have a "Provides: ", using the lower-case module name
prefixed by "php-"

the lower-casing is for consistency: otherwise we'd have php-pdo for PDO and
php-SimpleXML for SimpleXML.  Hope this works OK.

Comment 6 Tim Jackson 2006-02-28 17:23:48 UTC
Joe, you rock. Thanks for fixing this. Can't see a problem with lowercasing; I
can't remember whether RPM is case-sensitive when processing deps but either way
I'll look at doing a change upstream in PEAR_Command_Packaging that allows the
generation of lowercased deps for ext modules when creating RPM spec files using
"pear make-rpm-spec". Seems unambiguous whatever; I can't imagine there will
ever be two extensions with identical names but differentiated by case. The main
thing was to have *some* dep for packaged web apps to hang their hat on. With
this fix, we've got that. Great! :)



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