(Paste the actual approved Guidelines) |
m (→Synopsis) |
||
Line 6: | Line 6: | ||
This page describes items that need to be changed in the [http://fedoraproject.org/wiki/Packaging/PHP PHP Guidelines] or other items that need to be reviewed or ratified by the [http://fedoraproject.org/wiki/Packaging/Committee Fedora Packaging Comittee] and [http://fedoraproject.org/wiki/Development/SteeringCommittee FESCo] . | This page describes items that need to be changed in the [http://fedoraproject.org/wiki/Packaging/PHP PHP Guidelines] or other items that need to be reviewed or ratified by the [http://fedoraproject.org/wiki/Packaging/Committee Fedora Packaging Comittee] and [http://fedoraproject.org/wiki/Development/SteeringCommittee FESCo] . | ||
Section 2 is the current Guidelines to allow simple diff. | |||
= Guidelines for packaging PHP addon modules = | = Guidelines for packaging PHP addon modules = |
Revision as of 17:53, 16 February 2009
[[TableOfContents(3)]
Proposed Changes to PHP Guidelines
Synopsis
This page describes items that need to be changed in the PHP Guidelines or other items that need to be reviewed or ratified by the Fedora Packaging Comittee and FESCo .
Section 2 is the current Guidelines to allow simple diff.
Guidelines for packaging PHP addon modules
Different kinds of packages
There are basically two different kinds of php modules, which are packaged for Fedora Extras:
- PECL (PHP Extention Community Library), which are PHP modules usually written in C, which are dynamically loaded by the PHP interpreter on startup.
- PEAR (PHP Extension and Application Repository), which are reusable components written in PHP, usually classes, which can be used in your own PHP applications and scripts by using e.g. the include() directive.
While upstream used the same package and distribution format for both, creating RPMs has to take some differences into account.
Naming scheme
- PECL packages should be named php-pecl-PECLPackageName-%{version}-%{release}.%{arch}.rpm.
- PEAR packages should be named php-pear-PEARPackageName-%{version}-%{release}.noarch.rpm.
- Other packages should be named php-PackageName-%{version}-%{release}.%{arch}.rpm; %{arch} can be "noarch" where appropriate.
Please make sure that the PEAR package is correctly being built for noarch.
The PECLPackageName and the PEARPackageName should be consistent with the upstream naming scheme. The Crack PHP Extension would thus be named php-pecl-crack with the resulting packages being php-pecl-crack-0.4-1.i386.rpm and php-pecl-crack-0.4-1.src.rpm.
Note that web applications that happen to be written in PHP do not belong under the php-* namespace.
File Placement
Non-PEAR PHP extensions should put their Class files in /usr/share/php.
Requires and Provides
PEAR Packages
A PEAR package MUST have:
BuildRequires: php-pear(PEAR) Requires: php-pear(PEAR) Requires(post): %{__pear} Requires(postun): %{__pear} Provides: php-pear(foo) = %{version}
PECL Packages
A PECL package MUST have:
BuildRequires: php-devel, php-pear Requires(post): %{__pecl} Requires(postun): %{__pecl} %if %{?php_zend_api}0 Requires: php(zend-abi) = %{php_zend_api} Requires: php(api) = %{php_core_api} %else Requires: php-api = %{php_apiver} %endif Provides: php-pecl(foo) = %{version}
Other Packages
PHP addons which are neither PEAR nor PECL should require what makes sense (either a base PHP version or a php-api as necessary).
Macros and scriptlets
PEAR Modules
The php-pear package in Fedora Core 5 and above (version 1:1.4.9-1.2) provides several useful macros:
- %{pear_phpdir}
- %{pear_docdir}
- %{pear_testdir}
- %{pear_datadir}
- %{pear_xmldir}
These defintions for the .spec should be of interest:
BuildRequires: php-pear >= 1:1.4.9-1.2 Provides: php-pear(PackageName) = %{version} Requires: php >= 4.3, php-pear(PEAR) Requires(post): %{_bindir}/pear Requires(postun): %{_bindir}/pear
And here are some recommended scriptlets for properly registering and unregistering the module:
%post %{_bindir}/pear install --nodeps --soft --force --register-only %{pear_xmldir}/Foo_Bar.xml >/dev/null ||: %postun if [ "$1" -eq "0" ] ; then %{_bindir}/pear uninstall --nodeps --ignore-errors --register-only Foo_Bar >/dev/null ||: fi
PECL Modules
The php-pear package in Fedora Core 5 and above (version 1:1.4.9-1.2) provides several useful macros:
- %{pecl_phpdir}
- %{pecl_docdir}
- %{pecl_testdir}
- %{pecl_datadir}
- %{pecl_xmldir}
You may need to define a few additional macros to extract some information from PHP. It is recommended that you use the following:
%global php_apiver %((echo 0; php -i 2>/dev/null | sed -n 's/^PHP API => //p') | tail -1) %{!?__pecl: %{expand: %%global __pecl %{_bindir}/pecl}} %{!?php_extdir: %{expand: %%global php_extdir %(php-config --extension-dir)}}
And here are some recommended scriptlets for properly registering and unregistering the module:
%if 0%{?pecl_install:1} %post %{pecl_install} %{pecl_xmldir}/%{name}.xml >/dev/null || : %endif %if 0%{?pecl_uninstall:1} %postun if [ $1 -eq 0 ] ; then %{pecl_uninstall} %{pecl_name} >/dev/null || : fi %endif
Other Modules
If your module includes compiled code, you may need to define some macros to extract some information from PHP. It is recommended that you user the following:
%global php_apiver %((echo 0; php -i 2>/dev/null | sed -n 's/^PHP API => //p') | tail -1) %global php_extdir %(php-config --extension-dir 2>/dev/null || echo "undefined") %global php_version %(php-config --version 2>/dev/null || echo 0)
Additional Hints for Packagers
PEAR & PECL Packages
The source archive contains a package.xml outside any directory, so you have to use use
%setup -q -c
in your %prep section to avoid writing files to the build root.
PEAR Packages
To create your initial specfile, you can use the default template provided by the rpmdevtools package:
fedora-newrpmspec -t php-pear php-pear-Foo
Or you can generate one; make sure you have the php-pear-PEAR-Command-Packaging package installed:
pear make-rpm-spec Foo.tgz
Packages with Optional Requires
TODO: Some PEAR packages such as Auth have many other PEAR packages that are optional Requires. We need to discuss how to handle splitting up large packages such as this.
Other Items
No additional items required.