[users] Issues related to "dual-life" perl modules
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:
> Which when compared to the corresponding versions Makefile.PL show
> differences in dependencies:
> 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?
> Specfiles for Perl Modules - Perl core and dual life modules
> 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.
Systems and Operations
Office of Information Technology
More information about the users