[Catalyst] Re: list of perl-*.rpm files for a basic Cat install

[James S. White]

> 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.