Front page | perl.perl5.porters |
Postings from April 2010
Re: strategy advice needed (5.10 or 5.12?)
Thread Previous
|
Thread Next
From:
Todd Rinaldo
Date:
April 30, 2010 10:08
Subject:
Re: strategy advice needed (5.10 or 5.12?)
Message ID:
2070F3B7-D5E8-492B-90C7-24DA6070A078@cpanel.net
On Apr 29, 2010, at 7:13 PM, George Greer wrote:
> On Thu, 29 Apr 2010, Greg Lindahl wrote:
>
>> In the past there have been various discussions about getting a modern
>> perl onto CentOS 5.
>>
>> We have made 5.10 rpms based on the Fedora 12 rpms, and planned on
>> making them public, so that a bunch of us don't have to re-do this
>> work. Safety in numbers, I always say.
>
> I just started this at $WORK, although I'm changing the %_prefix of the packages so mine wouldn't help you much.
I've been working on my own $WORK RPM set for 5.12 and CPAN modules to go with. I ran into these issues so far:
1. The modules Class::ISA, Pod::Plainer, Shell, and Switch emit a warning message if you use the ones that come with core perl. My solution was to remove them during the %install step so they would not be released with perl. I can then address the dependency issues as I find them and notify Module authors to correct the missing dependencies. My RPM build architecture is designed like perl smokers in that it builds only a minimal dependency tree to make and test an RPM from spec so the alerts should come up quickly.
2. I've had quite a few 5.12 modules I've had to patch as part of the rpm gen process to deal with deprecation messages that show up in their test suite and thus later the module's use its self. This deals mostly with language syntax issues like use of 'defined %hash'. I've created tickets in the relevant RT queues but many of the modules are abandoned/neglected. I've actually taken quite a few modules in the past month as a result of trying to get rid of 5.12 deprecation messages in CPAN.
>> And, alas, RHEL 6 is going to ship perl 5.10. Presumably this means
>> Red Hat plans on backporting fixes. Or something. They don't exactly
>> have a great track record fixing bugs in what they ship. But, it will
>> be fairly easy to track whatever bugfixes they do backport.
>
> Ones I've filed bugs for they've been responsive to. Of course you could volunteer to help too.
I realize they're already in beta but I really wish they'd consider 5.12 for RHEL6, considering we're going to have to live with it for the next 5-7 years.
>> My quandry is whether I should retarget to 5.12. The only reason not
>> to is that 5.12 hasn't been packaged by a mainstream distro, yet, and
>> thus might have not had enough testing.
>>
>> What do you guys think?
My take is that 5.12 is a better target in that it has better upstream support potential. I suspect it will be much easier to get support and track issues for a perl that's in an active maintenance cycle.
I'd also encourage you to apply as few patches as possible to your RPM. I started with a mainstream distro spec for 5.10 to build out my 5.12. As I parsed through the patches that came with the RPM, what I discovered was how few had any relevance to 5.12 and probably even 5.10 perl. The distros don't seem to have a good way of detecting that a patch is no longer relevant or at least they don't remove patches often enough. In hind sight, I'd probably have been better off starting with no patches in my RPM.
--
Todd Rinaldo
Thread Previous
|
Thread Next