FW: [Dbix-class] Module versioning

[Peter Edwards]

>
> On Thu, 14 Apr 2011 16:34:56 +0100, Duncan Garland
> <Duncan.Garland at motortrak.com> wrote:
> > Do we conclude from this that most people use RPMs?
>

*Option 1 - RPMs*
*
*
*
Many larger places running Redhat/Centos do. It's so that they can automate
rollout and rollback and if the upgrade goes wrong they can uninstall the
rpm and reinstall the previous one.
More lately it's become popular to use a tool like puppet to remote install
these to large numbers of target hosts http://www.puppetlabs.com/

*
See how to make rpms of CPAN modules by Dave Cross (he gave an excellent
talk here at MiltonKeynes.pm on this)
http://www.slideshare.net/davorg/perl-in-rpmland-presentation

The automatically building repository he runs that holds >100 CPAN modules
http://rpm.mag-sol.com
If any module you need is missing you can write an rpm .spec file per his
instructions and he'll probably add it.

*Option 2 - build/deploy infrastructure*

An alternative approach you can consider if you have a reasonably
heterogenous set of servers is to build sets of shareable system libraries
and perls and perl libaries specific to each particular (operating system
version, perl version, app name and version).
- use perlbrew to build the different versions of perl you require and
target them to run from /opt/rh51/myperl588, /opt/rh55/myperl588,
/opt/rh55/myperl510, /opt/deb6/myperl512 etc. and not use /usr/lib/perl5 at
all (that example is one version of perl5.8.8 for redhat 5.1, one of perl
5.8.8 for redhat 5.5, one for perl 5.10 on redhat 5.5, one for perl 5.12 on
debian 6)
- install most system libraries like GD to /usr/lib64 and share across all
perls (then you can use yum or apt-get to install these)
- install problematic system libraries where you need different versions for
different perls to specific dirs below /opt/rh51/mylib588,
/opt/rh55/mylib510 etc. and have your perlbrew point to the shareable
library directories or use LD_LIBRARY_PATH in the environment
- use local::lib to create builds of complete sets of CPAN modules your apps
need on a per-app and per-perl specific basis, e.g.
/opt/rh51/cpan/myperl588/myappfoo, /opt/rh51/cpan/myperl588/myappbar,
/opt/rh55/cpan/myperl510/myappfoo, /opt/rh55/cpan/myperl510/myappfoo_v2
- collect all the above onto your build master and then you can easily
create a base install image for a particular o/s using g4l and then when you
get a new host you image install it then rsync the /opt directories across
and start using your apps

http://search.cpan.org/perldoc?App::perlbrew
http://search.cpan.org/perldoc?local::lib
http://sourceforge.net/projects/g4l/

What we're doing in our team at BBC WS is a simpler variant of the second.
The main part of the BBC uses the first approach.

Regards, Peter
http://perl.dragonstaff.co.uk
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.scsys.co.uk/pipermail/dbix-class/attachments/20110415/b8e=
f2fcb/attachment.htm