Front page | perl.perl5.porters |
Postings from June 2009
Re: Perl 5.10.1
From: Nicholas Clark
June 24, 2009 02:17
Re: Perl 5.10.1
Message ID: 20090624091701.GP33745@plum.flirble.org
On Tue, Jun 23, 2009 at 10:17:20PM -0700, chromatic wrote:
> On Tuesday 23 June 2009 20:39:21 David Golden wrote:
> > So in my opinion, we need a way for people to publicize useful
> > branches they maintain and we need an easy way for an admin of average
> > skill to easily build and install a perl from an arbitrary git branch.
> That sounds like an affordance for an admin of average skill (is that code for
> "doesn't follow p5p closely"?) to believe that a big wad of code vetted for
> stability, utility, and correctness even less often than bleadperl has the
> patina of support, or at least official tolerence.
> The existence of people willing to tolerate those kinds of antics to get
> useful features and necessary patches indicates something very important about
> the release process... especially considering the kind of abuse Red Hat
> received from p5p for pulling a patch which turns out to have caused a
> performance problem in a small but measurable subset of significant programs.
> (Careful readers have noted more than a hint of irony in the previous
And an avoidance of discussing precisely *why* they got slated - for making
a sequence of mistakes, compounding the problem, and not learning from it.
For the avoidance of all doubt, here is a reprint of my considered opinion
"Your random blog" has never been the right place to report a
bug. So to keep with the spirit, here's a fix to a bug, reported
on my random blog.
It seems that there is still a problem with RedHat's packaged perl
5.8."8". RedHat seem to have an aggressive policy of
incorporating pre-release changes in their released production
code. This would not be so bad if they actually communicated back
with upstream (i.e. me and the other people on the perl5-porters
mailing list), or demonstrated that they had sufficient in-house
knowledge that they didn't need to. But evidence suggests that
neither is true, certainly for 5.8.x
Let me stress that there has never been this problem in any released
Perl, 5.8.7, 5.8.8, 5.10.0, and it won't be in 5.8.9 either when it
comes out. The problem was caused by changes I made in the 5.8.x
tree that RedHat integrated. End users reported the first bug
something like 2 years ago, and RedHat closed it as "upstream patch"
rather than reporting back "you know that pre-release change you
made, that we integrated - well, it seems to have some problems". So
I fixed the cases I was aware of.
I'm human, and it turns out that that it wasn't all the cases. Once
I was made aware of this (by a RedHat user, note, never the RedHat
maintainer) I fixed the problems he reported, and went on a 2 day
trawl of CPAN to locate every other idiom that was going to be a
For their versions affected, RedHat merely need to put out a patch
integrating changes 31996, 32018, 32019 and 32025 which FIX IT, are
documented as FIXING IT, and are from NOVEMBER 2007.
Works on my machine. And anyone else's machine who is running my
code. Particularly my released code.
Although, the better fix is not to use the vendor's Perl release for
your production systems. Render unto Caesar the things which are
Caesar's and for yourselves, compile your own, and your own module
tree, from source you keep and control in your own version control
system, which changes only when you change it. In particular, if
you're not using ithreads anywhere you should compile without
ithreads support, which most vendors choose to enable. (It's not the
default, and it costs about a 10% slowdown). Anyone doing this would
never even have known that there was a problem with some vendor's
interpretation of perl.
No, it's still broken in RHEL5. root had changed everyone's $PATH
("it is my machine, after all"), and in my haste I'd not realised
that I actually just typed perl, not /usr/bin/perl. So to be fair
they are still asleep on the job. Where's I'm awake and doing this
stuff for free.
 Nor is your bug tracker. Upstream's own bug tracker is the O(1)
place where upstream reads about bugs in upstream's own
software. Not O(n) other people's bug trackers. The latter does not
 At least in some of their distributions. The only RedHat box I
have access to, and that's an account created 3 minutes ago, is "Red
Hat Enterprise Linux Server release 5" and their supplied
/usr/bin/perl doesn't have the bug.
 It has been a different matter for 5.10.0 in Fedora. For that,
the maintainer has been very communicative, and so we were able to
help him fix problems and get Perl 5.10.0 into Fedora Core 9.
 This was when I had a lot more free time than now, mainly
because I was having a break between jobs.