Bug#864544: libgetopt-long-descriptive-perl: option value : and :+ processing are very broken

Dominic Hargreaves dom at earth.li
Sun Jun 11 18:06:01 UTC 2017


On Sun, Jun 11, 2017 at 12:06:49PM +0100, Graham Cobb wrote:
> On 10/06/17 22:21, Dominic Hargreaves wrote:
> > Unfortunately we won't be able to fix either of these issues before
> > stretch releases because we're past the last upload date, even if 
> > fixes were available.
> > 
> > Given the last few releases of Getopt::Long have contained various
> > regressions and regression fixes I'd also be a bit wary of trying to
> > fix this in a stable point release, and indeed of diving in to try 
> > and fix the issue.
> > 
> > This is all a bit unfortunate but I'm not sure there is a solution
> > at this point.
> 
> I wonder if a solution for the immediate future might be to re-package
> the same version of Getopt::Long as available in (the latest update to)
> Jessie (which seems to be 2.42)? Obviously this would be missing some
> number of other bug fixes but it would, at least, not be a regression
> from Jessie.
> 
> As you say, it is too late to change the stretch release content, but
> that version could be made available in sid and in testing when it is
> opened up again (so fairly easily accessible to anyone who hits the
> bug), and could be made available as a stretch backport and in a stretch
> update release. After that is available, we could go back to repackaging
> the upstream version (which would hopefully include both fixes by then)
> and get that into testing to shake it down.
> 
> Or are there too many important changes to Getopt::Long since 2.42 to
> consider reverting?

I did briefly ponder that, but downgrading Getopt::Long in a point
release seems at least as invasive as the bug at hand. It's going
to be quite hard to tell whether that would break more than it would
fix due to people relying on the newer Getopt::Long.

And backports is not the right place for such things either (see
extensive discussions in recent Debian backports threads).

Dominic.




More information about the Perl-maintainers mailing list