> I really hope you aren't just pulling a list of rpms and then installing > them. Thats why package handlers like yum were invented.
I'm not. I'm moving them into the yum repos for the servers that get catalyst deployed on them. This "HOWTO" is just how I determine what goes into a given repo. Cfengine actually does the installation, removal, and configuration of the services. This basically defines what we call a "brick." > > There are a lot of them (~137), > > I am very surprised at this. I currently have 470 perl-*.rpm files in my > repo (for Centos 4 - I haven't currently got production Centos 5 cat). > The vast majority of these are catalyst/dbix-class and there > dependancies, although there is also a rebuild of the perl packages > themselves and the dual-life modules. This was just what it took to get the base catalyst going. If your particular App needs other perl modules, that goes in a separate brick. The philosophy to which we try to adhere is set-theory, sets of files define packages, sets of packages define "bricks", sets of these "bricks" make applications, sets of applications define a "system" (not to be confused, but often is with a "host system"), sets of systems define business functions, and sets of business functions serve customers/consumers. Now we can use this clearly defined, OO approach to system building to allow project managers (who often aren't technical) to work with business analysts (who often forget that the devil is in the details) to create new business functions at a high level, while the developers and sysadmins create packages, "bricks" and "systems" to serve the needs that aren't already met by existing components. Having a service catalog that can be re-ordered at a high-level (not unlike lego(tm) bricks) helps keep the business-function project managers out of the developers business. They only need know when a particular (higher-level) component is ready. This also "nudges" the architects to re-use existing work when possible rather than go off in an entirely different direction. It also eliminates the fear around change control as we know exactly which files we are changing will effect what *customers* which is really what the company officials really want to know. When they ask, "If I apply this patch, what is the impact?" They don't really care if a given service will be offline, they want to know what relationships with business partners will be effected. The Venn diagrams let us tell them whom and what with no ambiguity. > Note that the perl on all versions of RHEL5 prior to 5.3 (which is not > released yet) is not suitable for running DBIX::Class - see > https://bugzilla.redhat.com/show_bug.cgi?id=379791 Yes, we don't have any catalyst in production just yet (I'm hoping to see more of it) but perl will be re-rpmed and repo'ed before that happens. (Still in the assembling catalyst "bricks" phase) > Anyhow I would strongly suggest you look at cpanrpm effort and join that > campaign - see > http://www.perlfoundation.org/perl5/index.cgi?cpanrpm > http://lists.dave.org.uk/mailman/listinfo/cpanrpm Good information. I will certainly look into this. Is there an equivalent org for .debs? > cpanflute/cpanflute2 are very old and produce rather rocky rpms. > cpan2rpm is rather better but tends to miss dependancies. cpanspec is > very good - see > http://fedoraproject.org/wiki/Perl/cpanspec > http://cpanspec.sourceforge.net/ I had some issues with cpan2rpm in the past which caused me to standardize on cpanflute2. But this could be a "cut the ends off the roast issue now. I will re-visit cpan2rpm. Thank you. _______________________________________________ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/