[php-maint] Backport requirements exception for some packages (php5)

[Alexander Wirt]

On Mon, 16 Dec 2013, Ondřej Surý wrote:

> 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:
> 
> http://lists.debian.org/debian-backports/2013/10/msg00055.html
No, that message always expected that the package will get updated to the
version in testing.

> 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."
the testing rule existed a long time before the one with the upgrade path. I
am running backports for a long time now and it was always a base policy that
packages uploaded have to exist(ed) in testing. There were some exceptions
for a few packages that allowed them to come from unstable. Nevertheless
packages always had to exist in the archive. 

Backports is not a personal archive, it hosts packages backports from the
debian archive.

> > 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
> the testing.
> 
> 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:
> 
> http://lists.debian.org/debian-backports/2013/10/msg00069.html
> 
> 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?
You can give it a try. But I for myself don't want to change this basic
policy.

> 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.
Feel free to go the mozilla.d.n way.

Alex