[users] Issues related to "dual-life" perl modules

Matt Hyclak hyclak at ohio.edu
Sat Jul 12 15:08:24 CEST 2008


On Sat, Jul 12, 2008 at 02:40:47AM -0400, David Steinbrunner enlightened us:
> I fairly new to the RedHat/RPM/RPMForge scene but due to the environment of
> one of my customers I am currently swimming in it.
> 
> I'm currently working against RHEL4 and am required to have all software
> that is to be deployed to live servers rpm'ed.  Perl make up a large part of
> my customer's and my own world so both CPAN and application specific perl
> modules are needed in rpm packages.  RPMForge is the only added resource for
> yum to pull from so it helps determine what CPAN modules we have to manually
> create based on what is available.  I have notified the team of the customer
> about using the suggest list and contributing back, but that is not what I'm
> writing about.
> 
> I have found the need to work with several modules that according to their
> dependency requirements need newer versions of Scalar::Util and List::Util
> than RHEL4 and perl 5.8.5 provide out of the box.  These modules make up the
> Scalar::List::Utils package and has a "dual-life" status, meaning that it is
> a part of the core of perl but is developed and released on CPAN and outside
> of core development, while core is able to sync with the CPAN version when
> it is ready for a new release.
> 
> >From what I have seen RPMForge says that it makes sure not to replace base
> libraries and that these dual-life perl modules would be included under the
> base libraries heading.  From a perl developers perspective that should not
> be the case.  Many dual-life perl modules started life as a CPAN module and
> later became included in perl's core due to there high usage.  Not being
> able to update these highly used modules after features, bug fixes and
> memory leak patches are introduced makes things difficult.  Couple that with
> not having perl be able to be updated in a pleasant manor aside from moving
> to a whole new OS release makes it even worse.
> 
> Our efforts to create our own rpm of Scalar::List::Utils did not work
> because if you install in the vendor lib the existing and older
> Scalar::List::Utils modules get higher precedence and hence are seen first.
> If you try to install in the main lib you will find that rpm does not allow
> you to overwrite the existing older version.  We know that there are ways to
> modify perl's lib paths at runtime but consider this brittle.
> 
> There was talk of doing multiple unpleasant thing such as rebuilding a
> custom perl rpm without dual life modules.  They have managed to avoid doing
> such a thing in the past and would prefer to continue on that path.
> 
> I ended up coming across the following spec:
> 
> http://dag.wieers.com/rpm/packages/perl-Moose/perl-Moose.spec
> 
> Which when compared to the corresponding versions Makefile.PL show
> differences in dependencies:
> 
> http://search.cpan.org/src/STEVAN/Moose-0.38/Makefile.PL
> 
> I found that I was able to install this rpm which did not check against the
> Scalar::Util version.  This seemed dangerous one one level but on another
> seemed necessary given the current policies from Red Hat, rpm and RPMForge.
> I'm currently in the process of emulating this hiding of requirements to see
> if I can get by in creating all that I need.
> 
> Since I have been spending a lot of time related to this issue I wondered if
> I have been the only one to run into this and found that I was not:
> 
> Are we framing"dual-life" modules the wrong way?
> http://use.perl.org/articles/07/09/26/171235.shtml
> 
> Specfiles for Perl Modules  - Perl core and dual life modules
> http://gsd.di.uminho.pt/jpo/perl/specfiles/#PERLDUAL
> 
> As I said when I stated off, I'm no expert here so I may be off base
> somewhere and would like to be corrected if that is the case.  Is there some
> solution I'm not seeing to these issues?  Are my issues valid and if so is
> there a way to address them?
> 
> Any and all help in understanding this stuff is appreciated.
> 

In short, you are reading things right for RHEL 4 and I'm not sure that a
good answer exists. The good news is that in RHEL 5 and beyond, vendor
packages come before the distro packages in the perl path, so it is possible
to use newer versions of these modules.

I think Dag Wieers had a post about this in one of the rpmforge mailing
lists that explained some of the details I'm forgetting.

Matt

-- 
Matt Hyclak
Systems and Operations 
Office of Information Technology
Ohio University
(740) 593-1222



More information about the users mailing list