Stories
Slash Boxes
Comments

NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

use Perl

All the Perl that's Practical to Extract and Report

use Perl Log In

[ Create a new account ]

nicholas (3034)

nicholas
nwc10+useperl@colon.colondot.net
http://www.ccl4.org/~nick/

Perl 6 Groupie

Journal of nicholas (3034)

Wednesday June 04, 2008

10:08 AM

installing fixed versions

[ #36585 ]

Dear lazyweb...

This must be a solved problem. One has a version control system, and one has a tarball of perl, and tarballs of a bunch of known versions of modules that one has downloaded from CPAN, which makes one decoupled from any subsequent changes or deletions on CPAN. What one wants to do is build perl, and then build all those module versions, from the local snapshotted versions.

So what's the best way to do this? The naïve, brute force, way is to build perl, and then loop round all the tarballs in order, extracting them, running Makefile.PL, ignore there whining about missing dependencies (as we're going to get to them), run make install, and hope - ie skipping all tests. However, this is also getting trapped by Makefile.PLs that decide that they want to ask questions, or things that really wanted Module::Build, etc.

What would be really nice would be to do it in the dependency order that the cpan shell would work out, but the danger of just using it is that it goes off and tries (helpfully) to download things that it can't find, which is not what is wanted. (If we goof, and fails to have a suitable version of the module, it's a fail)

So what's the best tool for this job?

List all Journal entries

installing fixed versions More | Login | Reply

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.

Without JavaScript enabled, you might want to use the classic discussion system instead. If you login, you can remember this preference.

KISS (Score:1)

by Tony Finch (6392)

I just do it the simple way you describe, though I sort the modules into dependency order manually. This also allows me to patch modules before building, e.g. to fix broken Makefile.PL behaviour. Most interactivity can be suppressed using perl Makefile.PL </dev/null. For duplicate installations we just sync the installation tree onto the other target machines.
I don't have many different or fast-changing installations to manage, though.
- Re: (Score:1)
  
  by aallan (3252)
  
  Depressingly this is the same solution I use, I've tried other solutions. Automated install scripts, PAR, a couple of other things. None really worked as well.
Desynced mirror (Score:1)

by Alias (5735)

Pull a minicpan mirror at a point in time you think you like.

Then do a full install with the appropriate flags on to stop questions.

Then deleting any files where the atime hasn't moved.

Keep that shrunk minicpan as your install source.
CPANPLUS custom sources (Score:2)

by domm (4030)

Put all your tarballs in a dir, then:

cd /dir/with/tarballs ls -1 | grep tar.gz > packages.txt cpanplus /cs --add file:///dir/with/tarballs i The::Dist::That::Requires::All::The::Rest

For added savety, remove all cpan mirrors from the cpanplus config
- Re: (Score:1)
  
  by aallan (3252)
  
  Unfortunately that works okay right up until the point where you have XS and libraries that aren't installed as standard. At that point you installation becomes, rather custom.
Create and order an autobundle file (Score:2)

by cbrandtbuffalo (4462)

Another approach is to create an autobundle file and get it in the correct order. I made one attempt at doing this programatically a few years ago and posted it here:

http://perlmonks.org/?node_id=455259 [perlmonks.org]

I think there have been some more recent attempts to provide better dependency information, so I'm sure it could be updated. Also, it seems many people would have similar autobundles, so we should probably have a place for people to post their autobundles once they've got them in the correct order.