Bug#822463: perl: perlbug reports get rejected by exim4 due to long lines in 'perl -V'

[Dominic Hargreaves]

On Mon, Apr 25, 2016 at 06:11:50PM +0300, Niko Tyni wrote:
> Control: tag -1 patch
> 
> On Sun, Apr 24, 2016 at 10:25:23PM +0300, Niko Tyni wrote:
> > Package: perl
> > Version: 5.22.1-10
> 
> > So it looks like perlbug is broken on stretch/sid with the default exim4
> > configuration, and exim4 is the default MTA on Debian AFAIK. I think we
> > need to fix this.
> 
> > The options I see are
> > 
> > - make exim4 handle longer lines
> > - somehow shorten the longest line, probably by changing the way we call
> >   Configure
> > - make perlbug split or shorten overly long lines
> > 
> > I think the third option is the best one from a robustness point of view.
> > The 'correct' fix would be to teach perlbug to use MIME quoted-printable
> > or something like that, but that's probably overkill. Maybe just splitting
> > Config::myconfig() results where necessary and adding a warning to the
> > docs would be enough?
> 
> Tentative perlbug patch attached. Not sure where to put a warning if one
> is still needed.
> 
> Opinions before I take this upstream? Example reports wrapped at
> 200 and 100 characters attached. I think I prefer the 100-char one.

The patch looks good. However the example output looks ugly for me
(particuarly the 100-char one, where most of the patch descriptions
are uglified by a wrapping out of sync with my 80 character terminal).

If we are wrapping for technical reasons rather than aesthetic ones,
then the choice of max length should be based on those technical reasons.
>From [1] the maximum line length appears to be around the 1000 character
area. So call it 900 to be safe? I don't think we should wrap more
aggressively than is required to fit within that standard; that way, we
minimise the damage caused by wrapping, when displayed by MUAs which
themselves wrap.

I'm not sure what sort of warning is necessary; could you be more
specific here?

Cheers,
Dominic.

[1] <http://www.jebriggs.com/blog/2010/07/smtp-maximum-line-lengths/>