There is one person here who feels very strongly about the RPM based approach (not me) but I do agree that RT doesn't really get rebuilt very often. Since we actually run it in a VM on top of ESX, I almost feel like the kickstart isn't as necessary as I can make copies of the VM files and feel reasonably comfortable that way. Kickstart is awful nice when dealing with bare metal and being able to restore.
However I have restored exactly...never. So I'm not sure which way to go. Here I am looking at going from 3.6.x to 3.8 and it basically involves building a whole new machine. I can't imagine actually upgrading it in place based on everything that has to be installed. I'm curious what the RT people do to manage all the perl modules in a consistent way since I'm sure they build a ton of test machines over and over again. Jesse? Tim Cutts wrote: > > In an ideal world, I'd do what you're suggesting, and store those > RPM's in my own repository. In fact, I use Debian, not Red Hat, but > the principle is the same. It's particularly awkward at the moment, > though, because the new version of RT requires versions of some of > these perl modules which are considerably more recent than those in > Debian stable, so for testing purposes I've gone for the CPAN > approach. It does mean that things could go wrong with a future CPAN > update, but I don't tend to upgrade RT frequently (this is my first > upgrade since RT 3.4.2) > _______________________________________________ http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users Community help: http://wiki.bestpractical.com Commercial support: [EMAIL PROTECTED] Discover RT's hidden secrets with RT Essentials from O'Reilly Media. Buy a copy at http://rtbook.bestpractical.com
