Change proposal: drop runtime dependency on PEAR
by Remi Collet
Hi,
I don't even know if PEAR is going to exist in the near future (PHP7)
Some RFC (such as dropping php4 constructor) can kill it.
(a recent commit already kill it, but have been temporarily reverted)
To slowly move to PHP stack without pear, I'd like to remove dependency
on /usr/bin/pear for PECL extension.
This dependency is there only to "register" the extension in the pear
database, so the "pecl list" command will report it.
Here is a proposal for new scriptlets
# when pear installed alone, after us
%triggerin -- %{?scl_prefix}php-pear
if [ -x %{__pecl} ] ; then
%{pecl_install} %{pecl_xmldir}/%{name}.xml >/dev/null || :
fi
# posttrans as pear can be installed after us
%posttrans
if [ -x %{__pecl} ] ; then
%{pecl_install} %{pecl_xmldir}/%{name}.xml >/dev/null || :
fi
%postun
if [ $1 -eq 0 -a -x %{__pecl} ] ; then
%{pecl_uninstall} %{pecl_name} >/dev/null || :
fi
Notice: pear still required at build time for macro definition.
Notice; this also fix a circular dep issue (php-pecl-jsonc => php-pear
=> php-cli => php-common => php-pecl-jsonc)
Small issue, /var/lib/pear/pkgxml is own by php-pear.
So we also need to move this directory to php-common to avoid unowned
dir when pear is not installed (ex: /usr/share/php-metadata)
Notice, It can even make sense to store "composer.json" file here, to
have them in a centralized location instead of somewhere in %doc.
For pure-PHP pear libraries, there is 2 differents cases
- install time dep only on pear installer (so could use the same
solution, or simply switch from pear to github if the library is
maintained).
- runtime dep, when it used some PEAR classes (such packages have to
keep this dependency, and will very probably die with pear itself)
For now, I'm used to prefer the pear way, when possible, to avoid people
pulling a pear package, when the github one is already installed.
Comments ?
Remi.
P.S. this new scriplets make even more sense in SCL, where we have no
pear packages, except pear itself.
9 years, 2 months
Packaging of PHP library test classes?
by Shawn Iwinski
Problem: I've run into another case where one package
(php-guzzlehttp-guzzle) requires another package's (php-guzzlehttp-ringphp)
test classes but the test classes are not provided in any package. I'd
like to include test classes as sub-packages so they could be installed if
needed, but I'd also like to make them PSR-0 loadable instead of using
individual "/usr/share/tests/*" directories for each package which I've
done in the past.
I'm wondering in my case, could I create sub-package
php-guzzlehttp-ringphp-tests that installs it's test classes into either:
1) "/usr/share/php" so auto loading would work OOB
2) "/usr/share/tests/php" (nothing uses this yet) that could be used for
PSR-0 auto loading but would need to be specifically added to the include
path when running phpunit
Thoughts?
Shawn
9 years, 3 months