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.
- 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 :/
- 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?
- 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.
- 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.
- 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:
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#re... 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