Hey all,
Earlier today, Adam Williamson blew a gasket when trying to update ownCloud to the newest upstream release[0]. As a user of the ownCloud package, this is really unfortunate, as I look forward to new releases of ownCloud for EL7 and Fedora. However, as a packager, I sympathize with him, as PHP software has become increasingly difficult to deal with on this.
I've considered packaging some PHP based software myself; however, the rapid adoption of Composer and the complexity of dealing with that has put me off. What surprises me is that we don't yet have some kind of macro for "automagically" handling the ugly composer stuff.
For example, couldn't a "%phpcomposer" macro be set up to utilize an internal packagist that has php libraries and software installed as BuildRequires registered to enable utilizing it locally and a helper to generate the working autoloader necessary for being able to use unbundled PHP libraries?
Perhaps I'm missing something that would make that idea impossible, but I'm spitballing ideas here because it's pretty horrible that PHP software seems to be trending towards not being packageable.
Any thoughts on how the situation could be improved so that more people like Adam don't snap from trying to package PHP-based software?
[0]: https://www.happyassassin.net/2015/08/29/looking-for-new-maintainer-for-fedo...
Le 31/08/2015 02:39, Neal Gompa a écrit :
Hey all,
Earlier today, Adam Williamson blew a gasket when trying to update ownCloud to the newest upstream release[0]. As a user of the ownCloud package, this is really unfortunate, as I look forward to new releases of ownCloud for EL7 and Fedora. However, as a packager, I sympathize with him, as PHP software has become increasingly difficult to deal with on this.
I've considered packaging some PHP based software myself; however, the rapid adoption of Composer and the complexity of dealing with that has put me off. What surprises me is that we don't yet have some kind of macro for "automagically" handling the ugly composer stuff.
For example, couldn't a "%phpcomposer" macro be set up to utilize an internal packagist that has php libraries and software installed as BuildRequires registered to enable utilizing it locally and a helper to generate the working autoloader necessary for being able to use unbundled PHP libraries?
Probably people just miss what composer is, and that we don't really need it.
- composer is a dependency manager, great, thus composer.json give us useful information. But we have yum/dnf which does the work for our RPM package.
- composer create a autoloader, just something we can create differently. And PSR-0/PSR-4 rules helps us.
You can read http://blog.remirepo.net/post/2015/06/30/PHP-SIG-autoloader where I try to explain why the composer way doesn't work for Fedora (consumer autoload), and give a proposal (provider autoload) which is now used in lot of package / applications in Fedora.
You can also read the SIG documentation: https://fedoraproject.org/wiki/SIGs/PHP
I think, in most case, an application, where upstream use composer, could be package in a simple way:
: drop composer stuff rm -rf vendor* : replace it with a simple autoloader cat << 'AUTOLOAD' | vendor/autoload.php require_once '/usr/share/php/one_dep/autoload'; require_once '/usr/share/php/other_dep/autoload'; ... AUTOLOAD
I haven't look at owncloud package, probably doable.
I know we have a issue with "sabre" stack and required versions. (which could be fixed, perhaps with a FPC exception for Horde which still use the old 1.8)
Remi
Perhaps I'm missing something that would make that idea impossible, but I'm spitballing ideas here because it's pretty horrible that PHP software seems to be trending towards not being packageable.
Any thoughts on how the situation could be improved so that more people like Adam don't snap from trying to package PHP-based software?
-- 真実はいつも一つ！/ Always, there's only one truth!
php-devel mailing list php-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/php-devel
On Mon, Aug 31, 2015 at 1:00 AM, Remi Collet Fedora@famillecollet.com wrote:
Le 31/08/2015 02:39, Neal Gompa a écrit :
Hey all,
Earlier today, Adam Williamson blew a gasket when trying to update ownCloud to the newest upstream release[0]. As a user of the ownCloud package, this is really unfortunate, as I look forward to new releases of ownCloud for EL7 and Fedora. However, as a packager, I sympathize with him, as PHP software has become increasingly difficult to deal with on this.
I've considered packaging some PHP based software myself; however, the rapid adoption of Composer and the complexity of dealing with that has put me off. What surprises me is that we don't yet have some kind of macro for "automagically" handling the ugly composer stuff.
For example, couldn't a "%phpcomposer" macro be set up to utilize an internal packagist that has php libraries and software installed as BuildRequires registered to enable utilizing it locally and a helper to generate the working autoloader necessary for being able to use unbundled PHP libraries?
Probably people just miss what composer is, and that we don't really need it.
- composer is a dependency manager, great, thus composer.json give us
useful information. But we have yum/dnf which does the work for our RPM package.
- composer create a autoloader, just something we can create
differently. And PSR-0/PSR-4 rules helps us.
You can read http://blog.remirepo.net/post/2015/06/30/PHP-SIG-autoloader where I try to explain why the composer way doesn't work for Fedora (consumer autoload), and give a proposal (provider autoload) which is now used in lot of package / applications in Fedora.
You can also read the SIG documentation: https://fedoraproject.org/wiki/SIGs/PHP
I think, in most case, an application, where upstream use composer, could be package in a simple way:
: drop composer stuff rm -rf vendor* : replace it with a simple autoloader cat << 'AUTOLOAD' | vendor/autoload.php require_once '/usr/share/php/one_dep/autoload'; require_once '/usr/share/php/other_dep/autoload'; ... AUTOLOAD
I haven't look at owncloud package, probably doable.
I know we have a issue with "sabre" stack and required versions. (which could be fixed, perhaps with a FPC exception for Horde which still use the old 1.8)
Remi
Perhaps I'm missing something that would make that idea impossible, but I'm spitballing ideas here because it's pretty horrible that PHP software seems to be trending towards not being packageable.
Any thoughts on how the situation could be improved so that more people like Adam don't snap from trying to package PHP-based software?
[0]:
https://www.happyassassin.net/2015/08/29/looking-for-new-maintainer-for-fedo...
-- 真実はいつも一つ！/ Always, there's only one truth!
php-devel mailing list php-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/php-devel
php-devel mailing list php-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/php-devel
It sounds like we could use composer.json to automatically generate BuildRequires and Requires then? So a macro could be made to do this and create the autoloader automatically, right?
php-devel@lists.fedoraproject.org
-
Neal Gompa -
Remi Collet