Matisse Enzer wrote: > > On Feb 27, 2006, at 6:59 PM, Tyler MacDonald wrote: > >> #3 seems like the lowest maintenence. Maintaining on a .tar.gz in CVS >> seems easier than integrating diffs of the newest version whenever >> you want >> to upgrade. >> > > We definitely do NOT want to be integrating diffs if we can avoid it. > If we decide to modify a CPAN module (so far we have not) we would > probably check-in the unpacked tarball into our version control (and > probably send a patch to the author :-) > >> #2 has it's benefits too - you could even mirror all of CPAN, and >> just maintain a script with "install" commands to install the >> versions you >> want; >> >> install "KWILLIAMS/Module-Build-0.27_04.tar.gz"; >> >> etc. That makes both upgrading easy and makes your build process >> independant from the availablity of your favourite CPAN mirror. > > > Yes, it also means the build process can take of resolving > dependencies. The downside is having yet-another-repository. > > Whatever we do we would like to have a single-step build and release > process:
This is similar in nature to the Krang build process. http://krang.sourceforge.net Krang keeps a local copy of all of the CPAN modules it uses in it's source repo. Also, each module is installed locally to krang so that it can be installed without affecting an existing installation. Krang does the same thing with it's Apache/mod_perl server too. All of these are mainainted in the repository. This does mean that initial checkouts are rather lengthy. But the benefits are pretty big: Never having to track down issues with incompatible versions or strange Apache configs. Never having to worry about this application screwing with some other application. And this benefit will only increase when we have relocatable Perls in a few months :) -- Michael Peters Developer Plus Three, LP
