[Ottawa-pm] Repackaging Perl modules (was Wanted: 5 Perl Programmers)

[Mark Mielke]

On 02/26/2011 08:37 AM, Clayton Scott wrote:
> On Sat, Feb 26, 2011 at 2:12 AM, Dave O'Neill<dmo at acm.org>  wrote:
>> The biggest annoyance on Red Hat is that they retain ancient dual-lifed
>> modules as part of the core perl RPM, making conflicts inevitable when you
>> want to ship something that requires the newer one.  And they blame upstream
>> Perl for shipping them with the base language when asked about it :(
> This is why my preference (especially for RedHat) is to compile (and
> package) my own perl
> that's completely independent of the OS perl so that you don't have to
> stick to 5.8.9 (or worse)
> when 5.10.1 and 5.12.3 are available and no long bleeding edge.

Of course, the RedHat problem is really that they keep delaying the 
release of RHEL 6.0. If RHEL 5.x wasn't so old, most of the complaints 
would disappear...

$ rpm -q perl
perl-5.12.3-141.fc14.x86_64

I haven't found a need to install a module from CPAN in a long time for 
my server at home...

Personally, I do blame upstream Perl for "ancient dual-lifed modules". 
If the modules are going to branch so greatly - why not give them a new 
name? Core modules have an important part in development. They represent 
a particular baseline for "core behaviour" of Perl. If I write code that 
is tested on Perl 5.8.1, I expect to be able to freely use core modules 
in Perl 5.8.1, and that all of my testing will be valid. If some future 
version of a dual-lifed module changes behaviour - I expect my module to 
continue to function according to the old behaviour. If users start to 
upgrade these modules independent from the core, the resulting 
"Frankenstein" is not a supportable product.

-- 
Mark Mielke<mark at mielke.cc>