[Fedora-packaging] Open issues with the PHP guidelines

[Tim Jackson]

Jason L Tibbitts III wrote:

> Here are some open issues I see with the PHP guidelines.  

First of all, thanks for your work on this. As you and others may (or 
may not) have spotted from various activity in FE/RH Bugzilla/PEAR [1], 
I've spent a lot of time on PHP/RPM-related issues in the last few 
months and getting some concrete guidelines in place is great. I'm glad 
there is a bit of momentum behind this and I'm not the only one trying 
to make this stuff easier :)

(Background: I do a lot of PHP web application deployment and 
development, and package management/dependency resolution has always 
been a bugbear of mine; complete non-portability, complex setup and 
random problems due to missing deps are a regular feature of trying to 
deploy apps when all I want to do is "yum install [package]" and have a 
minimum of configuration necessary)

Note that my goal with the PEAR_Command_Packaging package in particular 
(forked, with the blessing and help of the PEAR maintainer, from PEAR 
core 'makerpm' command which it now obsoletes) has always been to make 
it so that "pear make-rpm-spec Foo_Bar.tgz" on Fedora will produce a 
spec compliant with FE guidelines. I'm not there yet, but getting 
closer. The php-pear-DB package that I submitted and which is in Extras 
was mostly a proof-of-concept to help establish what is a "good" spec 
file for a PEAR package.

> 1) The php(ABI) symbol.  The current PHP package (in FC5) provides
>    php-api = 20041225; is that sufficient?

Should be, I think although arguably "php" should provide php(ABI) or 
php-abi and "php-devel" should provide php(API) or php-api. The poor 
naming originated from my original suggestion over in bug #183227 I'm 
afraid :/

> 2) Somethig equivalent to perl(:MODULE_COMPAT_version).  The base PHP
>    package eventually provides a whole bunch of these indicating what
>    releases a module could have been written against and still work.
>    So php v6 can drop compatibility for anything before v4.2 and the
>    package can drop the corresponding :MODULE_COMPAT symbols.

Sounds reasonable. I'm not familiar with how it's done in Perl; can we 
copy it?

> 3) It seems there are plenty of extensions which are neither PEAR nor
>    PECL.  We need to figure out conventions for those.

We already have some in FE like php-shout. Personally I'm not 
uncomfortable with that convention, the only caveat being that there's 
no immediate way of distinguishing what's a "core" extension and what's 
a third party one.

> 4) Scriptlets for registering PEAR packages.

Several different variations that I've used over time, and ideas from 
others have meant that personally I've settled on (for PEAR >=1.4.7) the 
following fragments, as featured in Chris S's spec template:

%post
pear install --nodeps --soft --force --register-only \
               %{xmldir}/Foo_Bar.xml >/dev/null ||:

%postun
if [ "$1" -eq "0" ]; then
     pear uninstall --nodeps --ignore-errors --register-only \
          Foo_Bar >/dev/null ||:
fi

Indeed, these (minus the ||: which I will add) are used by default by 
PEAR_Command_Packaging both upstream and in my proposed FE package.

> 5) There is some functionality in php-pear which only made it in as of
>    some specific version, I think 1.4.9, which needs to be there in
>    order for something work work.  

Maybe this:

http://pear.php.net/bugs/7093

Also I fixed some stuff related to --packagingroot in 1.4.7:

http://cvs.php.net/viewvc.cgi/pear-core/PEAR/Command/Install.php?view=log#rev1.113
http://pear.php.net/bugs/6480

there are also
http://pear.php.net/bugs/6673
http://pear.php.net/bugs/6674

I would consider 1.4.7 as a minimum base version for future RPM-related 
stuff. Since 1.4.8 is broken, 1.4.9 is arguably the base.



Tim

[1] a non-exhaustive list includes:

RH #194852 - php Provides and Obsoletes mod_php
RH #173980 - pear makerpm docs problem
RH #183227 - PHP API needs encoding as a Provide ( php-api php(API) )
RH #173806 - php-pear does not have Provides:
RH #175074 - php-pear provides php-pear(PEAR_PEAR) not php-pear(PEAR)
RH #173808 - php-pear has too much bundled in it
RH #173810 - php-pear should be built separately from main php rpm
RH #173814 - pear makerpm does not generate deps on other PEAR packages
RH #194583 - php should Provide php-posix
RH #187891 - php package should provide mod_php, php-apache, php-apache2 
or similar
RH #173802 - template.spec naming convs
RH #173804 - php core rpm does not have Provides
RH #176725 - miscellaneous "pear makerpm" problems

PEAR #6373 - pear makerpm generates RPMs that cannot be uninstalled
PEAR #6375 - "pear makerpm" misc. improvements (rpm-depname, rpm-release 
options)
PEAR #6377 - "pear makerpm" post/postun improvements to cope with 
non-RPM installs
PEAR #6378 - "pear makerpm" generates packages that conflict due to 
depdb/.channels
PEAR #6480 - pear install --installroot option fails for pecl packages
PEAR #5959 - post/postun prob
PEAR #6047 - doc problem
PEAR #6963 - Duplicate Requires deps generated in some cases
PEAR #6971 - Create deps on php-[ext]
PEAR #7118 - Remove "doc hack" from template spec file

PEAR package PEAR_Command_Packaging - 
http://pear.php.net/package/PEAR_Command_Packaging

Fedora Extras
RH #176658 - php-pear-DB package
RH #185423 - php-pear-PEAR-Command-Packaging package
RH #196281 - php-manual-en package