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 _______________________________________________ users mailing list [email protected] http://lists.rpmforge.net/mailman/listinfo/users
