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

[Daniel Beyer]

Hi David,

Am Dienstag, den 16.02.2016, 08:57 -0400 schrieb David Prévot:
> Hi Daniel,
> 
> Le 16/02/2016 03:50, Daniel Beyer a écrit :
> > On Mon, 2016-02-15 at 10:07 -0400, David Prévot wrote:
> 
> >> I pushed some related changes to
> >> symfony too (in the wip/random_compat branch),
> > 
> > Do you intend to release this as 2.7.9+dfsg-2?
> 
> I don’t intend to so unless really necessary, but I assume keeping the
> 2.7 branch open until 2.8 makes it to unstable may be a good idea (I
> also assume that we’ll push the first version of 2.8 to experimental, so
> it won’t hold further 2.7 update during the NEW processing and will
> offer us a change to test and eventually fix the reverse
> (build-)dependencies before it gets uploaded to unstable).
> 

That sound reasonable and I would feel much more comfortable having 2.8
in experimental, first anyway.

> > Just asking, since 2.8.2 is on a good way and I'm wondering whether to
> > rebase my work against branch master (2.7.9+dfsg-1) or wip/random_compat
> > (potential 2.7.9+dfsg-2). Either is fine to me, just let me know.
> 
> If all the changes proposed in wip/random_compat make sense for 2.8,
> feel free to rebase your work on it. If it doesn’t feel free to reorder
> and rebase them in order to rebase your current branch into it (or
> simply cherry-pick what you feel is relevant, I don’t mind either way).
> I hope I’m understandable, it’s still a bit early for me now…
> 

Thanks for those commits. I cherry-picked them all, except for '693f865
Drop php5-memcached build-dependency now gone', since php-memcached is
in sid (but no php-memcache).


> > I guess changes are good we can release a 2.8.2 by end of this week.
> 
> Great. I only had a quick look at what you already done (so might be
> mistaken), and wonder if it wouldn’t be easier to stop patching the
> ”workaround for OR-ed versions”: we could simply let dh_phpcomposer drop
> the version (it does that by default when it can’t parse the version),
> and restore it’s meaning (the minimal version especially) in d/control
> (that means less patching, but more hardcoding in another file, so I’m
> not so sure). I don’t know if you already took care of autoload.php.tpl
> updating, but I can do it if you don’t want to put your head into it
> (like above, it’s a bit like hardcoding information from composer.json
> in another file, that’s why I usually handle d/control and
> autoload.php.tpl update in the same time).
> 

Great idea, especially since now almost all of those depends are against
packages build from src:symfony anyway (those I made "self.version" in
the patch). So I'll happily drop out that patch! (And btw. those
self.version depends wasn't a good idea anyhow).
Updating the autoload.php.tpl is next on my list.


> I add another idea (since I had to put my hand in the build process when
> I recently took care of php-symfony-polyfill): we could push
> php-symfony-security-{core,csrf,http,*} in the archive and have
> php-symfony-security depending on them. We might even push a big
> (php-)symfony package depending on all binary packages (using the main
> composeer.json file).
> 

Actually splitting php-symfony-security-* into separate packages came
into my mind today, too. I once was against doing this, but can't
remember the reason for it - and as of today I think splitting
php-symfony-security-{core,csrf,guard,http} would be the better
approach.
Regarding a php-symfony package, I personally think it is not of much
use. But I guess it does not harm either, so I'm okay with such a one.

> I’d be happy to work on that if you agree.
And I would be happy if you could work on it. ;-)


> Pleas note that I may not have much time to properly look at symfony
> before the weekend (so don’t let my suggestions block your update).
> 

Okay, good to know, this gives me a little more time to get the
autoload.php.tpl files and workaround for OR-ed versions done (my
business work tends to block my Debian related work a bit today).

Greetings
Daniel