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-fedora-epel-owncloud-packages/ > > -- > 真実はいつも一つ！/ Always, there's only one truth! > > > _______________________________________________ > php-devel mailing list > php-devel@xxxxxxxxxxxxxxxxxxxxxxx > https://admin.fedoraproject.org/mailman/listinfo/php-devel > _______________________________________________ php-devel mailing list php-devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/php-devel
