in reply to Building perl in chroot

you don't need a chroot environment for that. Just install perl in an alternative path, say /apps/perl-5.8.6.

When running Configure, pay attention to its questions, because at some point it will ask you where you want perl installed!. Modules will also become installed under the same location by default later.

And if you want to move to a chroot environment anyway, then, once your new perl is installed on a different path, fool your scripts to use it, while monitoring them with some tracing tool (truss, strace, etc.). to see which files are being accessed. Those are the ones you have to copy inside the jail.

Replies are listed 'Best First'.
Re^2: Building perl in chroot
by moot (Chaplain) on May 05, 2005 at 19:06 UTC
    Hmm.. perhaps I wasn't clear. I don't want to overwrite the existing perl on the build system, but I do on the deployment targets, which is the same perl in the same location (because it's using the packaged perl 5.6.1). I have no need to keep 5.6 on the deployed machines.

    If I build perl to live in, say, /apps/perl-5.8.6, it also wants to install its libraries there, no? At least, that's what I can figure from Configure..and that will break the package, because the paths will not reflect those in deployment.

    I used the Config.pm from the 5.6 installation to configure 5.8.6, but it's confusing to say the least - particularly this is unclear:

    In some special cases, particularly when building $package for distrib +ution, it is convenient to distinguish the directory in which files s +hould be installed from the directory ($prefix) in which they will ev +entually reside.
    I'll try your chroot idea, although it looks like that means I'll have to configure & build perl twice..
      you can use a soft link to make /apps/perl-5.8.6 point to the old directory where perl was installed on production machines.

      You can also use Configure -Dinstallprefix=/foo/bar option to tell perl that it should install itself in some place and then expect to reside in a different one when executed. But this feature will not allow you to test the new perl on the development machine.