[Catalyst] Re: list of perl-*.rpm files for a basic Cat install
James S. White
james at jameswhite.org
Mon Aug 18 22:00:17 BST 2008
I've already gone through this procedure:
My notes are here:
There are a lot of them (~137), Matt an I disagree on the using of CPAN
instead of real packages. I say "real" packages, because package management
is as much about being able to cleanly remove the files from a system as
Anyone who has been bitten by the:
"Uninstall is unsafe and deprecated, the uninstallation was not performed";
Using CPAN to manage your systems when you have a handful of boxes is fine, and
if you're doing development, I'd recommend it as well. But when you have over
200, having multiple versions of perl and CPAN modules all over the system
becomes an operational abyss.
On Mon, 18 Aug 2008, Aristotle Pagaltzis wrote:
> * Matt S Trout <dbix-class at trout.me.uk> [2008-08-18 12:00]:
> > Leave the system perl on there for system-provided things that
> > depend on perl.
> > Build your own applications perl for your applications.
> > You are allowed more than one perl on a system. I've got over a
> > dozen on the Shadowcat dev server and I know of people with
> > many more than that.
> FWIW, Dermot, I also suggest you go down this road. There are lot
> of reasons to do it that way. A major reason is that shoehorning
> CPAN into the distributorâs packaging model is always a bad fit
> because CPAN has no release process and every author handles API
> stability differently. You want full control over which version
> of which modules you install. (Strictly speaking you even want
> to keep your own vetted CPAN mirror. :-) )
> None of this, btw, is difficult.
> Aristotle Pagaltzis // <http://plasmasturm.org/>
> List: Catalyst at lists.scsys.co.uk
> Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
> Searchable archive: http://email@example.com/
> Dev site: http://dev.catalyst.perl.org/
More information about the Catalyst