On Mon, Apr 13, 2009 at 02:17:31PM -0700, Joshua ben Jore wrote: > On Mon, Apr 13, 2009 at 10:22 AM, Jonathan Rockway <j...@jrock.us> wrote: > > * On Mon, Apr 13 2009, Joshua ben Jore wrote: > >> /Now/ I can rebuild the set inside of half an hour which is /actually/ > >> about 28 minutes too long. More highly annoying things are CPAN.pm > >> being unable to install from a set of local tarballs. I tried for a > >> bit to manufacture some small bits of program to create a local CPAN > >> repo and had some success but not enough that my sysadmin incorporated > >> it. > > > > Uh, CPAN::Mini and CPAN::Mini::Inject? > > I wish I could recall why CPAN::Mini::Inject didn't seem appropriate. > I'll be redoing this thing anyway. I looked into Andreas' distroprefs > but never found enough time to suss it. I have a blind spot toward > CPANPLUS and didn't even consider it. > > Separately, I want to also solve this problem for ruby 1.8.6 + some gems. :-/ > > So, later, I guess I'll just report "Huzzah!" and that it all works > nicely when I remember to include all the good ideas already written.
At work, we have one architecture running one OS* We have perl built on a custom path, and all CPAN modules built for it. The whole lot (the install tree including binaries) are checked into subversion. We deploy from subversion. If we need to update an external module, we build it once, by hand, then check in the new and changed files. We have not bothered with burning time working out how to automate a build process for external code. It's not worth it for us. We suspect that what we have will be the most efficient way to scale to 2 or even 3 architectures. (Note, our internal code is not XS, and is laid out in subversion correctly for the live deployment. The odd bits of XS code are treated as external CPAN modules) Nicholas Clark * Or at least, this will become true soon.
