Hi folks,
recently, a lot of PHP packages have been either converted from PEAR format to composer or offered in both format. Some new software has been composer-only right from the start.
As far as I know, we only have tools for automatically dealing with PEAR format packages.
This is going to get worse as the most widely used 3rd party pear server software, pirum, has been deprecated in favor of composer. This renders more and more pear based installations useless.
http://pirum.sensiolabs.org/ https://twitter.com/fabpot/status/434256189258735616
Do you know how other distributions handle this? Is there any effort for (semi)automatic composer->rpm conversion tools?
Hi Ralf,
I have started to package composer a while ago but never finished; fedora started to package composer, too:
https://github.com/siwinski/php-composer-rpms http://repos.fedorapeople.org/repos/siwinski/php-composer/
Might be worth to use that base and contribute.
Best regards, Johannes
Am 12.03.14 07:51, schrieb Ralf Lang:
Hi folks,
recently, a lot of PHP packages have been either converted from PEAR format to composer or offered in both format. Some new software has been composer-only right from the start.
As far as I know, we only have tools for automatically dealing with PEAR format packages.
This is going to get worse as the most widely used 3rd party pear server software, pirum, has been deprecated in favor of composer. This renders more and more pear based installations useless.
http://pirum.sensiolabs.org/ https://twitter.com/fabpot/status/434256189258735616
Do you know how other distributions handle this? Is there any effort for (semi)automatic composer->rpm conversion tools?
On a related note, Composer is not installable in SLES 11 due to the lack of PHAR support. The phar module *is* built by the RPM spec, but the binary RPM is not included in either the SLES or SDK repos. (It is included in opensuse, btw.)
I opened a SR with Novell about this (#10855472361) but they closed it saying basically "too bad, mgmt didn't decide to include that package, try an enhancement request". I filed one of those (#88971) but have not received any feedback on it.
Whether or not php5-phar ever gets added to SLES 11 (pretty please?), I would strongly advise its inclusion in SLES 12 (or at least in the SDK), or it will make SLES an unattractive choice for PHP deployment, given how the PHP world is migrating to Composer.
I don't know how else to ask for this, having already gone through the "proper channels". Maybe the person packaging PHP for SLES 12 reads this list...
Whether or not someone makes a Composer RPM, having the phar module available so one can simply run 'curl -sS https://getcomposer.org/installer | php' as directed by the Composer docs will be a big help.
Andrew Daugherity Systems Analyst Division of Research, Texas A&M University
On Mar 12, 2014, at 1:51 AM, Ralf Lang lang@b1-systems.de wrote:
Hi folks,
recently, a lot of PHP packages have been either converted from PEAR format to composer or offered in both format. Some new software has been composer-only right from the start.
As far as I know, we only have tools for automatically dealing with PEAR format packages.
This is going to get worse as the most widely used 3rd party pear server software, pirum, has been deprecated in favor of composer. This renders more and more pear based installations useless.
http://pirum.sensiolabs.org/ https://twitter.com/fabpot/status/434256189258735616
Do you know how other distributions handle this? Is there any effort for (semi)automatic composer->rpm conversion tools?
On 14.03.2014 06:00, Johannes Weberhofer wrote:
Hi Ralf,
I have started to package composer a while ago but never finished; fedora started to package composer, too:
https://github.com/siwinski/php-composer-rpms http://repos.fedorapeople.org/repos/siwinski/php-composer/
Might be worth to use that base and contribute.
It's getting worse:
https://github.com/sebastianbergmann/phpunit/wiki/End-of-Life-for-PEAR-Insta...
I'm not sure which direction to take: The composer methods are not suitable for system installation like pear did, thus not suitable for packaging in general.
Maybe we should define a canonic include path (similar to /usr/share/php5/PEAR/) as a root for packaged "composer-based" libraries?
El 18/07/14 03:07, Ralf Lang escribió:
Maybe we should define a canonic include path (similar to /usr/share/php5/PEAR/) as a root for packaged "composer-based" libraries?
A word of advice.. don't. just slowly retire the PEAR package rpms when they stop being distributed, none of this frameworks for PHP library deployments are designed with Linux distributions in mind, neither the target audience use distribution packages for the task.
-
Andrew Daugherity -
Cristian Rodríguez -
Johannes Weberhofer -
Ralf Lang