develooper Front page | perl.perl5.porters | Postings from July 2009

Re: any 5.10.1 showstoppers?

Thread Previous | Thread Next
Dave Mitchell
July 25, 2009 17:13
Re: any 5.10.1 showstoppers?
Message ID:
On Sat, Jul 25, 2009 at 04:45:52PM -0700, Joshua ben Jore wrote:
> On Sat, Jul 25, 2009 at 4:13 AM, Dave Mitchell<> wrote:
> > Is anyone aware of any issues that would stop me releasing 5.10.1-RC1?
> > I'm aware of, and my intention for the 5.10.0 regression bugs
> > is to go with whatever gets fixed in the next day or two, then list
> > the remaining significant one in the "Known bugs" section of perldelta.
> I would very much like to ASCII-ify
> lib/Parse/CPAN/Meta/t/data/utf_16_le_bom.yml prior to the final cut.
> This apparently won't stop a real Debian packager but I'm the only one
> my $work has got. I've gotten far enough with this to think the fix
> ought to go into Parse::CPAN::Meta in Adam's SVN repo at
> I've been letting this slip off the top of my
> stack but I guess that's not a good idea right now. Sorry.

Well, I loosely followed the earlier thread, but not too closely.
Is the issue that something in the debian packaging system somewhere
can't cope with binary files in source code (which sounds strange)?

> For lack of anything smarter, I'd like to push into the
> Parse-CPAN-Meta CPAN module and use the documented procedure in
> pod/perlrepository.pod for "binary files." Parse-CPAN-Meta as a
> dual-use module then just takes on the technical debt of having a
> /copy/ of the packer tool. Annoying but not harbl.

I can't see any reason to change Parse-CPAN-Meta. The technique described
in perlrepository.pod is something that is done in core, not in the
distro. Ie in core we just replace utf_16_le_bom.yml with
utf_16_le_bom.yml.packed, and everything just magically works.

But: I thought that outcome of the earlier thread was that banning binary
files in the perl core was obsolete, and we should start dismantling the
.packed stuff; so I'm not keen on adding to it now.

> I notice that the CPAN version of Parse-CPAN-Meta is not integrated. I
> assume patching this issue involves a linear sequence from the CPAN
> version forward and applying the fix to core means upgrading from
> 1.38, past CPAN @ 1.39, to the currently fictional 1.40.

Um, core and blead are at 1.39, and have been since June.

> Other than the late date, is there a reason to not incorporate this?

I think that's a pretty good reason all by itself!

> If this isn't applied, work's .deb build process originally based on
> 5.10.0 will break. From prior emails about dpkg-source, the fix for my
> site appears to require incorporating some "testing" or "unstable"
> changes from Debian into Ubuntu. Kind of a PITA but not ultimately
> unsolvable.

Well, is the issue something that will affect all or many debian users, or
just your site?

But Pity stayed his hand. "It's a pity I've run out of bullets",
he thought. -- "Bored of the Rings"

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About