Re: [php-maint] Backport requirements exception for some packages (php5)
On Mon, Dec 16, 2013, at 14:28, Alexander Wirt wrote:
> On Mon, 16 Dec 2013, Ondřej Surý wrote:
> > Hi Alexander,
> > On Mon, Dec 16, 2013, at 14:14, Alexander Wirt wrote:
> > > On Mon, 16 Dec 2013, Ondřej Surý wrote:
> > >
> > > > Hi Alexander,
> > > >
> > > > On Mon, Dec 16, 2013, at 13:42, Alexander Wirt wrote:
> > > > > At the moment, I don't think we will accept it. Providing PHP in backports
> > > > > was always troublesome, as a lot of applications just stop to work with
> > > > > newer versions.
> > > >
> > > > Care to provide the evidence? AFAIK we never had a PHP in backports. I
> > > > would agree with you it this request came from some third party, but
> > > > here you have PHP packages provided and supported by the PHP Debian
> > > > team.
> > > php5.5 will make several php based applications incompatible to the php
> > > in bpo, wont't it?
> > We are not going to backport php5 5.5.x, just php4 5.4.x.
> > > > > And especially in that case it is a problem. If we want to keep
> > > > > with the 5.4.x upload currently sitting in NEW we will end with an
> > > > > unsupported branch (testing already has 5.5.x), which is imho not
> > > > > acceptable.
> > > >
> > > > Why? The upstream release process aims to keep the compatibility in the
> > > > 5.4.x branch and the Debian packagers are willing to support the 5.4.x
> > > > branch in the backports. Also the external services (dotdeb.org for
> > > > Debian, my PPAs for Ubuntu) proves that people are hungry to have latest
> > > > PHP running and I don't really see a reason why we can't provide that
> > > > from within the Debian infrastructure.
> > > And? backports come from testing. And you plan to support php5.4.x from
> > > testing for all the time?
> > That rule comes from the fact that we need straight upgrade path, right?
> > So this is not going to be a problem since jessie will have php5 >=
> > 5.5.0 and
> > wheezy-backports will always have php5 << 5.5.0, e.g. 5.4.x.
> Nope, this comes from the rule that software has to be in testing before
> it gets uploaded to backports.
That contradicts what you have said earlier:
and what the http://backports.debian.org/Contribute/ says:
"*To guarantee an upgrade path* from stable+backports to the next
stable, the package should be in testing."
> This rule ensures that package gets at least a minimum testing before it goes to backports.
I don't think this has the required effect since you recompile the
package with different build dependencies. The only reasonable way how
to ensure the package has the minimum testing is when the maintainers do
So would it be possible to convince you if we:
a) check the tests (make check) results for regressions?
b) (optional) provide (some) autopkgtests?
> And we don't plan to lift that rule.
Well I thought this is the case that's why I have asked if we could be
granted an exception, but that email got ignored:
so I have digged deeper and I haven't actually found the rule that would
forbid it. But I don't want to play on the 'lawyered' note.
That's why I have asked you to step out of the box, since it feels to me
that the general argument is: we have never done this before and we are
afraid that it might break something.
While we cannot overrule the possibility of breakage (and regressions),
we have pretty good grasp about what's happening with upstream about the
release process, and we don't want to change the packaging vs wheezy,
just the upstream versions, so I am pretty confident that nothing will
break more than regular security (or s-p-u) updates.
> But not within backports.
This seems to be said with really authoritative tone. Could we at least
discuss this in the wider audience, so it doesn't feel like the single
developer against the Debian backports overlords?
If we had a personal DPAs then I wouldn't be pleading for this to
happen, but we don't have them yet and we don't have the buildd
infrastructure, so the Debian backports is the only option we have.
Ondřej Surý <firstname.lastname@example.org>
Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server