Re: [Catalyst] Re: list of perl-*.rpm files for a basic Cat install
On 18 Aug 2008, at 22:00, James S. White wrote: My notes are here: http://github.com/fapestniegd/wcyd/tree/master/scratch/procedures/el5/installing_catalyst_on_el5 I really hope you aren't just pulling a list of rpms and then installing them. Thats why package handlers like yum were invented. 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. 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 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 Other comments... 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/ Nigel. -- [ Nigel Metheringham [EMAIL PROTECTED] ] [ - Comments in this message are my own and not ITO opinion/policy - ] ___ 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/
Re: [Catalyst] Re: list of perl-*.rpm files for a basic Cat install
On 22 Aug 2008, at 14:44, James S. White wrote: [Regarding number of rpms needed for cat/DBIX] 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. Thinking about it, I always rebuild rpms in a clean environment (mach for the older stuff - Centos 4.x, mock for newer) which means my repo contains not just the rpms I put on a production box, but also the ones I need to make those build, test etc. A production server currently has 235 perl rpms on it. 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? As I understand it the cpanrpm effort is aiming to build on similar work done for debs. I only have one debian box though (not at work) and that uses CPAN instead. Nigel. -- [ Nigel Metheringham [EMAIL PROTECTED] ] [ - Comments in this message are my own and not ITO opinion/policy - ] ___ 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/
Re: [Catalyst] Re: list of perl-*.rpm files for a basic Cat install
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/
Re: [Catalyst] Re: list of perl-*.rpm files for a basic Cat install
On Friday 22 August 2008 16:44:01 James S. White wrote: 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? There are http://alioth.debian.org/projects/pkg-catalyst/ and http://alioth.debian.org/projects/pkg-perl Lots of people in these groups are packaging Perl modules and (more importantly maybe) maintaining these packages. The tool used by the Debian Perl group (and myself whenever I need to package a module) is dh-make-perl. You can also use cpan2dist in CPANPLUS : ### build a debian package of DBI and it's prerequisites, ### don't bother running tests cpan2dist --format CPANPLUS::Dist::Deb --buildprereq --skiptest DBI ### build a debian package of DBI and it's prerequisites and install them cpan2dist --format CPANPLUS::Dist::Deb --buildprereq --install DBI -- Bogdan Lucaciu http://www.wiz.ro/ ___ 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/
Re: [Catalyst] Re: list of perl-*.rpm files for a basic Cat install
On Mon, Aug 18, 2008 at 04:00:17PM -0500, James S. White wrote: I've already gone through this procedure: My notes are here: http://github.com/fapestniegd/wcyd/tree/master/scratch/procedures/el5/installing_catalyst_on_el5 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 adding them. That's what .packlist files are for - you can almost always do rm -r `cat /path/to/distribution/.packlist` and if you can't I tend to consider that a bug. -- Matt S Trout Need help with your Catalyst or DBIx::Class project? Technical Directorhttp://www.shadowcat.co.uk/catalyst/ Shadowcat Systems Ltd. Want a managed development or deployment platform? http://chainsawblues.vox.com/http://www.shadowcat.co.uk/servers/ ___ 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/
Re: [Catalyst] Re: list of perl-*.rpm files for a basic Cat install
Aristotle Pagaltzis wrote: Point taken; the usual advice of compiling Perl and running a vetted CPAN mirror is motivated by the more common situation where the number of large Perl apps to run, which tend to be sensitive to module versions and may each require a different version of the same module, is not a priori bounded. Trying to handle that situation via the package manager of the distro is asking for the impossible. If you have a large number of boxen and only a bounded and small number of Perl apps to support, then using the package manager is a more sensible proposition, but few people are in that position. To provide one other perspective on this... I found it convenient to package Perl in .deb files on Ubuntu. It actually can support dependencies on specific package versions or package version minimums. There's no good automated way of building packages (dh-make-perl notwithstanding), but it can be done and giving everything a once over is probably a good idea. Having them in packages is also convenient because then if I need to do a new deployment, I can build a package list, and use that for Perl module installation. I build a local repository and give developers access, so they can get any modules I build, rather than relying on them to install them all on their own. I can also be sure that the versioning across the entire system is the same, because they just pull package updates. And yes, it does have drawbacks: * Upstream providers will sometimes over-package modules, which can resuilt in conflicts when building new ones. (perl-modules and libcatalyst-modules-perl come to mind.) One can either build their own to replace, or force overwrite it. * No easy way of applying CPAN updates (yet). I manually scan an RSS feed and consider upgrades, but there's no easy way to vet it. (This is a terrible solution, I just haven't come up with a better one yet.) * Doing the work of CPAN yourself. You're essentially doing a lot of the work CPAN would do for you (finding and building dependencies, especially). * I sometimes end up building the same module a couple times for different architectures (amd64 vs. i386). ___ 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/
Re: [Catalyst] Re: list of perl-*.rpm files for a basic Cat install
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 John Lee wrote: | * Upstream providers will sometimes over-package modules, which | can resuilt in conflicts when building new ones. (perl-modules | and libcatalyst-modules-perl Yeah libcatalyst-modules-perl should die a cold, horrible death. | * I sometimes end up building the same module a couple times for | different architectures (amd64 vs. i386). (for general info - sounds like you probably know this, John :) The dh-make-perl script is very useful, and they are good about giving commit bits for folks with patches. We use it a lot. There's also the debian-perl project which has an SVN repo and a friendly bunch on IRC. regards, oliver. - -- Oliver Gorwits, Network and Telecommunications Group, Oxford University Computing Services -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIrD/C2NPq7pwWBt4RAo6pAKCKER6H+Te6Y2HtduKt5dQ6D6k8KgCaA4d4 9ZLlGwLO8eBL+exrNEe/ch4= =htZO -END PGP SIGNATURE- ___ 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/
Re: [Catalyst] Re: list of perl-*.rpm files for a basic Cat install
I've already gone through this procedure: My notes are here: http://github.com/fapestniegd/wcyd/tree/master/scratch/procedures/el5/installing_catalyst_on_el5 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 adding them. 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 [EMAIL PROTECTED] [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. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/ ___ 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/ ___ 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/
