On Thu, Jul 06, 2017 at 09:01:21PM +0200, Cyril Brulebois wrote: > Dominic Hargreaves <d...@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 <d...@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.
That makes perfect sense, sorry for the misunderstanding! Dominic.