On 7/4/06, Jason L Tibbitts III <tibbs@xxxxxxxxxxx> wrote:
>>>>> "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?
If I understand things correctly, there are basically two types of php
packages, those written in C or some other language which create a .so
file which gets loaded by the php.ini file, and those that are written
in php which only add .php files otherwise known as "class libraries".
pecl modules create .so files, pear modules are only .php files, and
other modules can be either or. For example, php-Smarty is only .php
files and php-mysql adds .so and .ini files.
"pear" and "pecl" packages are just like php-Foo packages except that
they have been classified into one of these two types and are tared in
a way in which they can be installed using the /usr/bin/pear or
/usr/bin/pecl commands.
Packages which are .php files only such as php-Smarty or php-pear-Foo
need only require php >= version they say they require, or if they do
not say, then php >= current version (or no version) should be fine.
I have some php-pear packages which specifically indicate they need
php >= 4.2.0 some that say they need php >= 4.3.0. If these versions
are specified by the package, they should be indicated in the spec
file (IMO).
Packages which make .so files and load them in .ini files should
require a php-api version. The api version can be obtained like so:
%define apiver %((phpize --version 2>/dev/null || echo 'PHP Api
Version: 20041225' ) | sed -n '/PHP Api Version/ s/.*: *//p')
Requires: php-api >= %{apiver}
packages such as php-mysql or php-pecl-Foo should have this.
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)
Note pear and pecl modules both need to get path infomation in the same way:
%define php_peardir %(pear config-get php_dir 2> /dev/null ||
echo undefined)
%define php_peardir %(pecl config-get php_dir 2> /dev/null ||
echo undefined)
Say calling this macro "php_peardir" is not a good idea, instead a
better name would be "php_phpdir", "php_datadir" etc..
I think it was determined that the API macro of:
%define apiver %((phpize --version 2>/dev/null || echo 'PHP Api
Version: 20041225' ) | sed -n '/PHP Api Version/ s/.*: *//p')
was considered "better" for some reason, I will have to find out which
bug this was commented on to try and find out why.
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.
Smarty is not an application, it is just like any other pear package
in that it adds a "class library" which can be used by php developers.
If there is something wrong with installing it in %_datadir, where
should it go instead?
Here are the subbested %post and %postun scriptlets from the ticket
Ralf cited earlier:
Requires(%post): /usr/bin/pear
Requires(%postun): /usr/bin/pear
How is this different than:
Requires(post): php-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.
Why are these no longer wanted? First I am told to put them in, and
now I am told not to. Can we get clarification on why and if it is
better practice not to, can we update the Scriptlets wiki page to
indicate this?
Do PECL modules need any scriptlets?
PECL modules will need the exact same scriptlets only they will use
the /usr/bin/pecl command instead of the /usr/bin/pear command.
However /usr/bin/pecl is currently broken and a bug needs to be filed
for this upstream.
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.
Sure, is fedora-newrpmspec powerfull enough to do this? I think this
is all that is required:
Provides: php-pear-Foo-Bar >= %{version}-%{release}
Provides: php-pear(Foo_Bar) >= %{version}-%{release}
If we want to cater to newbs I really don't think we will ever have
any name collisions with:
Provides: php-Foo-Bar >= %{version}-%{release}
Provides: php-Foo_Bar >= %{version}-%{release}
In the rare (and possibly will never happen) case that there is a name
collision we can require that these provides be entered manually to
avoid such collision.
--
Fedora-packaging mailing list
Fedora-packaging@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-packaging
