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

Re: any 5.10.1 showstoppers?

Thread Previous | Thread Next
Joshua ben Jore
July 25, 2009 19:19
Re: any 5.10.1 showstoppers?
Message ID:
On Sat, Jul 25, 2009 at 5:13 PM, Dave Mitchell<> wrote:

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

I've moved what I deem your most important question to the top.
There's a fix to this in Debian according to Niko. It is to write
'(3.0 quilt)' to any Debian package attempting to use the
lib/Parse/CPAN/Meta/t/data/utf_16_le_bom.yml file. This change is not
available on my Ubuntu Hardy Heron/8.04/(april 2008) and I haven't
worked out yet how to get it. I /guess/ for Debian/Ubuntu, it makes
the upgraded toolchain a requirement to be fulfilled prior to
packaging 5.10.1. It does appear integrated in Intrepid
Ibex/8.10/(October 2008).

So assuming the Debian/Ubuntu core packagers are ok, this affects
anyone else making .debs out of 5.10.1 on systems with the unfixed
toolchain. I'd assume that's a small list. I think it's more than my
site but probably not /many/ people. I think perhaps I don't think
this matters as much now that I'm writing this later email.

WRT the actual change:

The easier change *seemed* to change the perl distribution so it used on the file. Doing that means releasing
Parse-CPAN-Meta-1.40 and then cherrypicking it. I checked that CPAN
has 1.39 and is current with the SVN repo at 1.39 and that maint-5.10
did not have it. I didn't think to check blead too.

> 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)?

Yes, but it's ok "in the future" if you can get the new enough Debian
packaging tools.

> 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.

I thought it was proper to keep the code in core and CPAN in sync. In
this case, core could pack the file and it'd magically work.

> 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.

Given what I've just learned about Debian packaging... maybe?

>> Other than the late date, is there a reason to not incorporate this?
> I think that's a pretty good reason all by itself!

Agreed. I only raised this because it was the only thing that actually
broke with 5.10.1 when I tried the RC0.


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