Front page | perl.perl5.porters |
Postings from June 2009
Re: Perl 5.10.1
From: Nicholas Clark
June 24, 2009 02:34
Re: Perl 5.10.1
Message ID: 20090624093421.GR33745@plum.flirble.org
On Tue, Jun 23, 2009 at 07:27:40PM -0700, David E. Wheeler wrote:
> That leaves out those of us who detest packaging systems, and hate
> having to maintain scripts that apply patches, constantly having to
> decide what patches we need and what we don't for production.
But you are not in the majority.
> I think that core Perl should be released far more often than it is.
> If something breaks, people go back to the previous version and wait
> for the next release in, say, just six weeks.
On Tue, Jun 23, 2009 at 11:35:19PM -0700, David E. Wheeler wrote:
> On Jun 23, 2009, at 11:12 PM, Rafael Garcia-Suarez wrote:
> >To me, detesting packaging systems is a bit like detesting version
> >control systems... and I know the guts of rpm enough to know how
> >hateful they can be.
> I'm not talking about the source code for packaging systems; I likely
> know less than you do. What I know is that they are always behind the
> release curve, often integrate unreleased patches (!), and don't use
> stuff I've compiled and installed myself as dependencies. And the time
> they save me compared to compiling is negligible compared with the
> time I typically spend configuring the software to work once it's
> >Going back is not easy, unless you never install any modules, and
> >don't use any program that embeds perl or that is linked with
> >libperl.so (like mod_perl, or things like the vim editor on my ubuntu
> >system). Perl is actually pretty low on the dependency chain.
> Only a fool would upgrade a production box to a new release and
> completely replace the existing version in the process. One typically
> installs it in a completely separate root, and if it fails, you delete
> that version without any effect on the installed version. Any admin of
> average skill can do this, and should.
Which, it seems, it why vendors stick to exactly the release that they
first packaged on an OS.
/usr/bin/perl on my OS X 10.3 machine stayed at "5.8.1 RC3" for its entire
life. On every Unix system that I have access to, /usr/bin/perl is still
5.8.8, even though it's 6 months since 5.8.9 shipped, and it's a seamless
upgrade incorporating a lot of bug fixes.
At all the companies I have worked for, upgrading the production perl has
not been something undertaken lightly. In all bar two it was outside the
development department's control. In the two where it is, it's still not
something done lightly, because it's so low down the dependency chain.
In a controlled environment the risk isn't of catastrophic failure, as that
can be backed out quickly. It's the risk of subtle bugs, the implications of
which aren't discovered for a while, by which point enough has been built
that subtly depends on the new release that it's as much of a risk rolling
back as pressing forward. As a specific example, the BBC took years to
migrate from 5.004_04 (note, _04, not _05). And even now, I think that the
"official" production perl is 5.6.1.
Many end users, like it or not, are using the vendor supplied perl. Be that
an OS vendor, or the internal vendor in their company. And, like it or not,
many vendors package up whatever is current, and stick to that. So if there
are frequent, slightly dodgy releases, we end up with an ecosystem of many
dodgy releases, each with different bugs to work round. And a reputation for
slighty dodgy releases. And upgrade roulette - gambling that the new release
will not introduce bugs worse than the bugs that it fixes.