[Pdx-pm] Package Management

[Chad Granum]

I sit very firmly in the camp that your application should use a
different perl install, seperate from the OS version. Many OS's (read:
redhat) ship broken, or restricted perls. If you install your own Perl
you can build it to the default/normal specifications, or add in
custom flags. In addition your modules install to the new perl and do
not conflict with the system perl.

The best way I find to accomplish this is to user perlbrew
(http://github.com/gugod/App-perlbrew)

Use perlbrew to install whatever version of perl you want ot use for
your software. Switch tot he installed perl, use cpan/cpanm to install
deps. Done. I do all my development under perlbrew now.

-Chad

On Fri, Apr 13, 2012 at 1:32 PM, Andrew Clapp <andrew.clapp at gmail.com> wrote:
> I have had some good and bad experiences with this and I'm wondering
> if there's a better way.  I first ran into this when writing code for
> some company way back when that just grew and grew and had millions of
> dependencies.  Then later while supporting RT (Request Tracker
> http://bestpractical.com/rt/), I had to deal with it again.  They
> provide an install script that "fixes" your deps, and sometimes it
> worked, sometimes it didn't and it seems it was affected mostly by
> which OS and version of OS was being installed upon, and how much
> other perl hackery had happened there before.  For small to medium
> environments, or instances where there are large lists of dependencies
> supporting a central thing like imaging software (libjpeg, libpng,
> libgif, zlib, etc) I find that using on of the cpan(+/-) tools works
> well.  But when you get to a larger system that is under constant
> changing demands, there are still problems that creep up that are less
> than fun.
>
> Can anyone point me towards a good discussion or good articles on
> various solutions to the conflicts that can arise from using both cpan
> (including plus and minus) options and linux (rpm, yum, apt) or bsd
> options (ports, pkgsrc)?  When you wear both hats as a sysadmin and
> developer, it creates obvious conflicts and there must be a good
> solution.
>
> -ASC
>
> --
>
> Andrew S. Clapp
> Aeonic Enterprises
> _______________________________________________
> Pdx-pm-list mailing list
> Pdx-pm-list at pm.org
> http://mail.pm.org/mailman/listinfo/pdx-pm-list