[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 Hyclak
Systems and Operations 
Office of Information Technology
Ohio University
(740) 593-1222

More information about the users mailing list