[pkg-php-pear] Symfony 2.8 (Was: Re: Are you planing to release a Symfony 2.7.9+dfsg-2?)

[David Prévot]

Hi Daniel,

Le 19/02/2016 13:05, Daniel Beyer a écrit :
> Am Dienstag, den 16.02.2016, 10:11 +0100 schrieb Daniel Beyer:

> It took a bit longer, but I think I have something for you to look at
> and work on in branch 'wip/2.8.2'.

Great, thanks, diving into it right now (already pushed a pair of
additional stuff after looking at your last commits).

> Please pay special attention to symfony-common, which is part of
> eliminating the Workaround-OR-ed-versions-are-not-supported.patch -
> especially since I'm not entirely sure, if this really complies with
> Debian standards. Please let me know if you have doubts with it.

I’m not convinced by the upper bound. E.g.,
src/Symfony/Component/Validator/composer.json requires
"symfony/translation": "~2.4|~3.0.0", but depending on
phpsymfonyversion-2.8 adds a break for php-symfony-translation (>=
2.9~), so we are more restrictive than upstream.

Worst, e.g., src/Symfony/Component/Locale/composer.json requires
"symfony/intl": "~2.7|~3.0.0", but php-symfony-locale (via
phpsymfonyversion-2.8) “only” breaks php-symfony-intl (<< 2.4~) so the
lower bound from upstream is not respected. I’d rather (see us) work on
#765899 than adding another package with additional (wrong) dependency
layer. I furthermore assume it will make the dependency solver (from
apt, aptitude, etc.) work more difficult than it needs to be.

Looking at your approach makes me wonder if we could rather generate a
${symfony:Depends} containing, e.g., symfony-event-dispatcher (>= 2.4)
if a package requires symfony/event-dispatcher (no matter the version),
that will ensure the lower bound we need for our autoload.php
workaround, but I guess that will be pretty complicated (maybe worse
than fixing #765899), and will not be enough to fix the lower bounds
from upstream.

To be honest, I don’t mind continuing adding some lower bounds (as well
as updating the d/*.autoload.php.tmp files) myself in debian/control to
match every composer.json files if you are annoyed by doing it yourself
(I’m the one who introduced them for the autoload.php stuff, and I’m
ready to assume that thing until we can do better).

I’ll start working on updating d/control the dumb way while reviewing
upstream changes, do not hesitate to scream ASAP if you don’t want that.

> I have two task open for the weekend regarding Symfony:
> - Write some helper do deal with the autoload.php.tpl (since this is
>   very error-prone and time-consuming to maintain)

I’ll double check that the “if (stream_resolve_include_path(…” rules
from require-dev still match the ones from suggests during my review. I
guess you’ve been right to replace the commented require_once since the
cost of having multiple require_once on the same file should not cost
much at execution time, while maintaining a clever list of stuff that
don’t need to be included twice is a pain to maintain. Having a helper
to maintain them all would indeed be pretty useful.

> - Do some test upgrades (e.g. 2.4 to 2.8 and 2.8 to 3.0)

Assuming you mean something like stable to unstable, stable to
experimental, unstable to experimental, yes, that’s useful too (and if
you have more tests idea, the better). piupart should help testing such
upgrades. There is already an automatic instance for that, but you may
of course make tests in other conditions ;).
<https://piuparts.debian.org/sid/source/s/symfony.html>

Regards

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/20160220/54f4f72f/attachment.sig>