Dominic Hargreaves <[email protected]> (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 <[email protected]> (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.
signature.asc
Description: Digital signature
