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

[Daniel Beyer]

Hi David,

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

Great!


> > 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 in the
> archive), since Stretch should be released with a recent enough PHP
> version. [0] 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 made that choice with owncloud already (that
> uses polyfill too), but I’d be happy to make the latest version
> installable on Jessie (as the current Jessie version is installable on
> Wheezy).
> 
>  0: https://lists.debian.org/debian-devel-announce/2016/01/msg00002.html
> 

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


> > 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 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.


> I guess I’ll start working on symfony-polyfill itself after
> paragonie/random_compat. not sure we really want all the packages built
> from it, but I haven’t made up my mind yet.
> 

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.

> > For now I concentrate on Symfony itself. I let you known if I stumble
> > across more issues.
> 
> I uploaded php-phpdocumentor-reflection yesterday night (already
> accepted by the never sleeping ftpmaster) that might be needed as a
> build dependency (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). I also uploaded php-psr-cache (already accepted
> too), but that’s for symfony 3.0 ;).

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.)



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?


I'm continue trying to get the (build-time) tests running. I doubt this
will be done today. I'm not sure how much time I can spend next week on
src:symfony, but I at least dedicate the weekend to it.


Greetings
Daniel

[1] https://github.com/symfony/symfony/blob/master/src/Symfony/Component/Debug/Resources/ext/README.md
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL: <http://lists.alioth.debian.org/pipermail/pkg-php-pear/attachments/20160214/d0624a07/attachment.sig>