Front page | perl.perl5.porters |
Postings from July 2009
On Sat, Jul 25, 2009 at 5:13 PM, Dave Mitchell<davem@iabyn.com> 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 uupacktool.pl 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. JoshThread Previous | Thread Next