Re: [PLUG] perl and CPAN (was Re: Upcoming December talk)

[Morgan Jones <morgan@morganjones.org>]

On Oct 19, 2012, at 4:52 PM, Rich Freeman wrote:

> On Fri, Oct 19, 2012 at 2:22 PM,  <brainbuz@brainbuz.org> wrote:
>> I'm a professional system administrator and author of several cpan
>> modules, so I could easily give a good talk on managing your CPAN modules.
> 
> I can't speak to how to maintain the modules from the perspective of a
> module author.  However, I highly recommend using tools provided by
> your distro to make CPAN behave in a sane manner.  I use g-cpan when
> there is a need to install some random cpan module.  Then I know the
> module will be maintained when perl is updated, or removed cleanly
> when I want to get rid of it, and so on.
> 
> I have nothing against secondary package managers, but they're not a
> substitute for clearly documenting your dependencies/etc.  Anybody
> with a decent distribution won't be using the secondary package
> manager anyway, and the distro maintainers lives are much easier when
> dependencies are clear and not automagical.
> 
> Sure, tools like CPAN and other secondary package managers can make
> things easier for users up-front.  The problem comes 5 years later
> when there are still random files lying around or causing problems
> because they were placed outside of /usr/local and yet they aren't
> properly registered with the package manager.
> 
> All that said, I wouldn't mind hearing a CPAN talk - especially one
> that focused on how not to have all the issues I described.  Maybe I'm
> just using it wrong.  :)
> 
> Rich


Rich et al,

I agree with you, unfortunately I'm not sure there's universal agreement in the Perl community or among my clients--some use RPMs, some use CPAN or, often, a combination of both (!).

At least in CentOS/Redhat, there are Perl modules that aren't available as RPMs or are just out of date as RPMs.  This leaves the developer/sysadmin the choice of installing from CPAN, potentially causing the problem you describe, or living with what's available as an RPM.

Ultimately a lot of module dependencies seems to lead to dependency hell when moving a Perl script between distros or even distro versions.  This is more acceptable in the case of a significant piece of software but,  in my opinion, an unnecessary hassle when moving small to mid-sized utility scripts between systems or between clients who of course don't use homogenous Linux versions.

We're getting to the root of my original question though and why I make an effort to use as few modules as possible when developing a script designed to be portable.  Yes, reinventing the wheel isn't great but it only has to be done once as opposed to resolving dependencies in disparate environments which has to be done each time the script is moved.  Oh and the wheels I generally use are usually straightforward--I'm a systems person and I usually just need small string or data transformations that are easy-ish to invent.

thanks for the comments so far everyone.

-morgan

___________________________________________________________________________
Philadelphia Linux Users Group         --        http://www.phillylinux.org
Announcements - http://lists.phillylinux.org/mailman/listinfo/plug-announce
General Discussion  --   http://lists.phillylinux.org/mailman/listinfo/plug