Re: About PHP packaging with composer things

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, Aug 31, 2015 at 1:00 AM, Remi Collet <Fedora@xxxxxxxxxxxxxxxxx> 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-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

[Index of Archives]     [Fedora Users]     [Fedora Desktop]     [Fedora KDE]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]

  Powered by Linux