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
--
Fedora-packaging mailing list
Fedora-packaging@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-packaging
