<div class="gmail_quote">On Wed, May 11, 2011 at 1:37 PM, Fred Moyer <span dir="ltr"><<a href="mailto:fred@redhotpenguin.com" target="_blank">fred@redhotpenguin.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">





A repeating theme that I have been seeing with enterprise scale perl<br>
applications is that deploying rpm based versions of Perl modules in<br>
production environments has several problems that seem to remain<br>
unsolved.<br></blockquote><div><br>This does come up quite a bit: at my last, current, and next employer, even :)  Some of the problems here are distro/rpm, some are Perl/CPAN.<br><br>Distro problems (from a developer perspective, not meant to be exhaustive):<br>




<br>* no control over how perl is built<br>
* CPAN packages installed outside of RPM to the system perl site shoot RPM metadata dependency to heck<br>* dependent packages are not retested when a newer package is built (aka: no smoke testing) (e.g. perl-Moose is upgraded, but perl-MooseX-* aren't retested)<br>





* RPM's automatic Perl metadata generation is geared towards the system perl only (resulting in spurious metadata if not disabled and an independent Perl package is built)<br><br>CPAN problems:<br><br>* versioning only specifies a lower bound (e.g. currently not possible to specify "won't work with Moose > 1.99")<br>





</div><div><br>I do[1] a bit of work with Fedora's Perl SIG, as well as in-house for our servers.  On the Fedora side I've introduced RPM dependency filtering (for cleaner RPM metadata) and automatic "-tests" subpackages to provide a way, post-build, to test the installed package.  To date, only the dependency filtering code has really taken off; I haven't had the time to drive the -tests subpackages the way I want.<br>





<br>At $work, I've taken to building independent Perl RPMs: put them somewhere convenient (e.g. %global _prefix /usr/perls/5.xx.yy),  disable metadata generation, etc.  This works, and is pretty straight-forward, but then what to do with CPAN packages?  Do we build and install one-by-one as we do in Fedora, or do we try to cluster them in larger RPMs?  How do we handle dependency metadata in a way that 1) works(!), 2) doesn't conflict with the system perl, and 3) makes sense?  How can we take advantage of the (very) large number of CPAN RPMs already created over in Fedora?<br>





<br>I've also started tinkering with <a href="http://sitecustomize.pl" target="_blank">sitecustomize.pl</a>.  This is a little known feature that causes a properly named/located script to be invoked "very early" when perl is invoked; I'm looking at it mainly to fiddle with @INC so we can stay away from other, erm, less-desirable hacks.  It's enabled when perl is compiled with the -Dusesitecustomize option.<br>





<br>Also...  I really, really miss the git plugin for cpanminus.  Being able to maintain a stack of modules outside for per-application purposes was quite nice :)<br><br>==<br><br>I do find myself going back and forth, but the basic things I now try to stick to are:<br>

<br>1) don't mess with the system perl -- your SAs or your enterprisey vendor will hate you<br>

2) use RPM for the biggies -- but maintain a parallel set of packages not dependent or conflicting with system perl<br>
3) don't use automatic metadata generation, but...<br>4) use RPM metadata, even if you have to manually add it<br>5) provide the standalone cpanm/perlbrew scripts as part of the core perl package (pref. in a subpackage)<br>




<br></div>                         -Chris<br></div><br>[1] "once and future" work might be a more accurate statement...  I'm starting to get back into it, but my Real Life intruded rather forcefully last summer and pretty sharply constrained my free time.<br clear="all">





<br>-- <br>Chris Weyl<br>Ex astris scientia<br>