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

[Daniel Beyer]

Hi David,

On Sat, 2016-02-20 at 17:43 -0400, David Prévot wrote:
> Hi Daniel,
> 
> Le 19/02/2016 13:05, Daniel Beyer a écrit :
> > Am Dienstag, den 16.02.2016, 10:11 +0100 schrieb Daniel Beyer:
> 
> (...)
> 
> > 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.
> 

Actually I had bad feelings about symfony-common myself, but wanted to
hear your unprejudiced opinion. I'm totally fine with abandoning it.
Sorry for the extra work I caused you with it, hence I think it was
worth a shoot (next time better be done in a separate branch).


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

Fixing #765899 is the way we should go. I put it on my list of things to
dig into.


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

No, neither does it annoy me nor do I mind the extra work. I only fear
mistakes that could sneak in. But as long we both carefully check on
this, we should be able to minimize them.


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

As said I'm fine with it and what I saw in wip/2.8.2-nocommon looks good
to me so far.

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

Yes, please double check it. I have no working helper so far, but I want
to make it produce an output similar to how current autoload.php.tpl
files look like. Thus I'm happy you're okay with how they are right now.


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

I manly had this in mind in respect to symfony-common. Since we won't
have it, I guess it's enough for now to relay on piuparts.d.o.


Greetings
Daniel
-------------- 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/20160221/93612840/attachment.sig>