Dominic Hargreaves <dom@earth.li> (2017-07-06):
> + debian-perl as it possible affects how we deal with FTBFS module
> packages.
>
> On Wed, Jul 05, 2017 at 07:46:39AM +0200, Cyril Brulebois wrote:
> > Hi Dominic,
> >
> > Dominic Hargreaves <dom@earth.li> (2017-07-04):
> > > 1) this commit is identical to those now in upstream release
> > > candidates.
> > > 2) This has now been filed as #867164 (sorry that this was missing
> > > before)
> >
> > Thanks for the update, much appreciated.
> >
> > I have to say that giving you a green light to update perl in stable
> > with this kind of fix makes me a little nervous, sorry. :(
>
> Okay, it would be useful to know in a bit more detail why you think
> this, as it doesn't seem any different from other similar fixes to
> perl we have requested in the past (and we've learnt our lesson from
> lack of mass rebuild testing where that was an issue previously)
Well, I'm not the one having accepted past proposed-updates, and since
I've been active on quite a number of {jessie,stretch}-pu requests over
the past few weeks, that was mainly a hint for other release team
members that I wasn't going to green or red light this request myself.
> But anyway, there are two options:
>
> 1) proceed with the update as proposed. This should be fairly low risk
> since we have test-rebuilt all packages build-depending on perl and found
> no regressions, and the problem it is fixing only affected a handful
> of unusual cases. Given the lack of bug reports, I assume the imperfect
> base.pm change hasn't actually affected anyone in the real world, but of
> course that might be a rash assumption.
>
> 2) work around the problem by patching away the issue like we have
> for stretch in the half dozen or so affected packages. This would leave
> jessie's perl in a slightly awkward state in carrying around for the
> rest of its days a patch that was rejected by upstream in favour
> of another one. But in practice it may not make all that difference.
> And probably the risk in doing this is slightly less in not touching a
> core package, though it is a bit more work.
>
> Overall I'm in favour of 1) but happy to defer to you. Does anyone
> else in pkg-perl have an opinion on this?
I see a third one:
0) Wait from someone else from the release team to comment on this.
Hope this clarifies.
KiBi.
Attachment:
signature.asc
Description: Digital signature