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