[pkg-php-pear] Symfony 2.8 (Was: Fixing FTBFS in symfony before the PHP migration)

[David Prévot]

Hi Daniel,

Le 14/02/2016 12:24, Daniel Beyer a écrit :
> On Sun, 2016-02-14 at 08:12 -0400, David Prévot wrote:
>> Le 14/02/2016 06:53, Daniel Beyer a écrit :
>>
>> (..)
>>
>>> 1. symfony-acl now is standalone
>>
>> I already intended to package it today ;).
> 
> Great!

It’s in the NEW queue now.

>>> 2. symfony-polyfill
>> […]
>>> We could either package this thing (and its dependencies, see below) or
>>> patch Symfony to not depend on polyfill (choosing the proper
>>> replacements, like e.g. php7 or the mbstring extension).
>>
>> My initial (lazy) preference would be to not care (i.e., use the proper
>> dependencies rather than adding yet another compatibility layer […]
>> On the other hand, that also means we wont be able to
>> install (directly as we mostly can now, or via backport) many packages
>> from Stretch into Jessie. […]

> I think it would be cool to be able to install it on Jessie (e.g. for
> providing composer for Jessie).

Let’s (try to) go this way then!

>>> symfony-polyfill has the following external dependencies:
>>> ircmaxell/password-compat
>>
>> Is that really useful (given that it offers PHP 5.5 compatibility, while
>> even Jessie ship with PHP 5.6)?
> 
> I guess we better leave this out, maybe providing an empty
> symfony/polyfill-php56 depending on php >= 5.6.
> 
>>> paragonie/random_compat
>>
>> This one if for PHP 7 compatibility, so yeah.
> 
> Agreed.
> 
>>> symfony/intl
>>
>> Is that really useful (we already have php5-intl | php-intl in the archive)?
> 
> We already have this one, as it is build from src:symfony.

I still don’t know if it makes much sense to provide a non empty one.

>>> I would prefer packaging symfony-polyfill above patching Symfony. What's
>>> your opinion on this?
>>
>> I’ll prepare paragonie/random_compat (so we’ll be able to provide at
>> least the polyfill for php7, and patch the rest away as a first shot).
>> If we really want that, I can also take care of the other two.
> 
> I'm not sure, but patching Symfony might could get a bit complicated and
> hard to maintain. I really would prefer to not do this.

Sure, Symfony is huge enough not to add more complication into it, let’s
export the patching and complication in symfony-polyfill that I hope
will be a lot simpler.

>> I guess I’ll start working on symfony-polyfill itself after
>> paragonie/random_compat.

> I think we should have all the binaries provided by it, but have the
> needles ones (compatibility for extensions and php <= 5.6) just as empty
> dependency packages.

Sounds like a plan. If we change our mind, it’s straightforward to
remove a binary package, it’s only packaging work to make it a non empty
package (it doesn’t involve third party processing in the NEW queue,
that is amazingly fast these days by the way).

>> I uploaded php-phpdocumentor-reflection […]
>> (beware, it’s hacked to make it use php-parser 1.*
>> instead of 0.9.*, and fails part of its own testsuite, but its a better
>> start than nothing).

> Thanks for this one, sadly it does not work for src:symfony:
> 
> Testing src/Symfony/Component/PropertyInfo
> KO src/Symfony/Component/PropertyInfo
> PHP Fatal error:  Interface 'PHPParser_NodeVisitor' not found in /usr/share/php/phpDocumentor/Reflection/FileReflector.php on line 50
> 
> (Probably because php-parser 1.* does not provide such an interface.)

Yet it should according to /usr/share/php/PhpParser/Autoloader.php (line
103), to be investigated (later).

> One more thing:
> The C extension 'php5-symfony-debug' seems to be unavailable (and no
> longer needed) for php7 [1]. Should we continue to build it for php5 or
> simply drop it out completely?

Let’s continue to provide it for php5 until we actually migrate to php7
if that’s not too much work.

Cheers

David

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-php-pear/attachments/20160214/f451b1f2/attachment.sig>