[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [Fedora-packaging] PHP packaging policy notes



>>>>> "TC" == Tom Callaway <Tom> writes:

TC> Sure, especially if the php owner doesn't see the value in adding
TC> it.

OK, it's now gone; in it's place is

Requires: php >= current PHP version

Perl would use Requires: perl(:MODULE_COMPAT_current-perl-version)
here.

I suppose we'll need a macro to extract the current PHP version.

%define php_version %(php-config --version 2>/dev/null || echo 0)

Should we use the full path to php-config here?  The Ruby specfile
template doesn't.  The Ruby template also wraps its macros like
%{!?ruby_sitelib: ...}; do we need to do the same?

Here are the macros I've seen, renamed to be consistent with what
other language templates use (php_*).  I also replaced any default
values provided with either "undefined" or "0".   These macros only
have to result in something which is syntactically correct when things
aren't yet installed; I'm concerned that providing a meaningful
default value would both become outdated (as uses of "php4" will soon
be) and might still produce something that looks OK even when a BR is
missing.

For PEAR modules:

%define php_peardir     %(pear config-get php_dir  2> /dev/null || echo undefined)
%define php_peardatadir %(pear config-get data_dir 2> /dev/null || echo undefined)
%define php_pearxmldir  %{php_peardir}/.pkgxml
%define php_version     %(php-config --version 2>/dev/null || echo 0)


For PECL modules:

%define php_apiver  %((echo 0; php -i 2>/dev/null | sed -n 's/^PHP API => //p') | tail -1)
%define php_extdir  %(php-config --extension-dir 2>/dev/null || echo "undefined")
%define php_version %(php-config --version 2>/dev/null || echo 0)


Modules which are neither PEAR nor PECL will need to use whichever
locations and macros are appropriate.  Extensions like php-shout will
need the PECL defines, for example.

I looked at php-Smarty and found that it gets installed essentially as
a web application.  It drops itself in %_datadir/Smarty.  At first
glance that seems pretty odd.  I guess it's not really a PHP module at
all.

Here are the subbested %post and %postun scriptlets from the ticket
Ralf cited earlier:

Requires(%post): /usr/bin/pear
Requires(%postun): /usr/bin/pear

%post
/usr/bin/pear install --nodeps --soft --force --register-only %{php_pearxmldir}/PEAR_Command_Packaging.xml >/dev/null

%postun
if [ "$1" -eq "0" ]; then
  /usr/bin/pear uninstall --nodeps --ignore-errors --register-only PEAR_Command_Packaging >/dev/null
fi

I removed the ||: bits as my understanding is that they are no longer
required or wanted.

Do PECL modules need any scriptlets?

Finally, should we consider providing macros to assist in converting
between the various representation of the package name?  We have
php-pear-module-name, PEAR_Module_name and probably a few others.

 - J<


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]