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