gnu@perl has asked for the wisdom of the Perl Monks concerning the following question:

I am in an environment where very strict control is the rule. We have dozens of machines of the same OS but only 1 box, our development machine, has a compiler on it.

The reason for this is to force developers to test in one environment and apply changes to production environments. This causes a problem with the upkeep of perl. To make things more difficult, my predecessors did not standardize anything. Each machine is slightly different in the @INC and placement of the perl binary.

What I wanted to do was have the ability to use a centralized server, our development box, to load and make modules. Then once the modules had 'make test' done have the directory they are in NFS mounted to the various servers that they may do a 'make install' of the modules needed.

Great in theory, but I have run into a problem when it comes to @INC on the various boxes. When the modules go through 'make' the Makefile is given the destination for 'make install'. This destination is different among machines of the same perl revision so a 'make install' from the NFS mounted file system fails on the target machine.

After a file has gone through 'make' is there a way to specify a new install path when performing 'make install'? Or does anyone have a good way of distributing modules to various boxes?

Replies are listed 'Best First'.
Re: Distributed Perl Modules
by Abigail-II (Bishop) on Aug 29, 2003 at 15:19 UTC
    It's been done, although it's a bit painful. I strongly suggest you consult the p5p archives, and search for relocatable binary.

    Of course, the right way to go for your situation is to standardize the location of perl (I prefer /opt/perl/, while /opt/perl/bin/perl linked to either /usr/bin/perl or /usr/local/bin/perl, depending on the OS).

    Abigail

[reply]
Re: Distributed Perl Modules
by hardburn (Abbot) on Aug 29, 2003 at 15:16 UTC

    I don't see a good solution. It seems your predecessors wanted tight control, but didn't implement things properly to actually do it. Your production boxes should be boringly identical. Best solution is to present a case to managment that the production boxes need to be wiped and rebuilt from a single box using disk mirroring (assuming the hardware is the same--if not, you're in even worse).

    ----
    I wanted to explore how Perl's closures can be manipulated, and ended up creating an object system by accident.
    -- Schemer

    Note: All code is untested, unless otherwise stated

[reply]
Re: Distributed Perl Modules
by herveus (Prior) on Aug 29, 2003 at 15:16 UTC
    Howdy!

    It sounds like you need more strictness. How did these dozens of machines come to be so variable? Do you have a way to rebuild any machine from scratch? Maybe you need to spank each non-conforming machine.

    yours,
    Michael

[reply]
Re: Distributed Perl Modules
by traveler (Parson) on Aug 29, 2003 at 15:36 UTC
    For pure perl modules how about creating a directory on each machine ( e.g. /<whatever>/perl) and mounting your NFS share there. If you add that to @INC then everyone will see it in the same place. Make the same directory on the development machine as a symbolic link to the real directory. Do the install to /<whatever>/perl.

    --traveler

[reply]
[d/l]
[select]
Re: Distributed Perl Modules
by gnu@perl (Pilgrim) on Aug 29, 2003 at 15:26 UTC
    Thank you all. This is the same (painfull) solution I had come up with. Also, each of our production boxes are not necessarily the same architecture, all Sun Solaris, but different platforms.

    I was hoping there was some uniquely brilliant solution that someone had come up with. I didn't think I would find one, but it was worth a shot.

    Personally I would prefer to reinstall a standardized perl dist among the servers, but that will be a hard sell to upper management, not to mention a ton of work in relocating all the pre-existing modules that are out there.

    Looks like I am going to develop a plan and tell management what must be done.

[reply]
Re: Distributed Perl Modules
by blue_cowdawg (Monsignor) on Aug 29, 2003 at 16:00 UTC

        After a file has gone through 'make' is there a way to specify a new install path when performing 'make install'? Or does anyone have a good way of distributing modules to various boxes?

    If you can't NFS (or AFS) mount from a centralized server then you could possibly negotiate a standard where you do two things:

    1. Establish a standard where you have a place where all third party software goes. In my shop we use the standard point of /usr/local/software and further every version of the software we are "keeping" gets installed in a subdirectory named after its version for instance /usr/local/software/perl-5.8.0
    2. With that in mind you then put in symoblic links as needed to that standard places. Such as /usr/bin/perl would be a symbolic link to /usr/local/sofware/perl-5.8.0/bin/perl.
    The beauty of having the subdirectories with mutltiple versions is that if you have a developer who's Perl script needs a different version than what you have in "production" they can just change the shebang line as needed. In a previous shop we actually had cases where scripts used in production would only run under older versions of Perl and blew up under the latest and greatest.

    From what you have described doing what I propose won't be easy, but often good things aren't easy to do.

    Once you have established this standard then building new modules and installing them will go much smoother.

    Peter L. Berghold -- Unix Professional
    Peter at Berghold dot Net
    Chat Stuff: AIM:  redcowdawg
    Yahoo: blue_cowdawg
    Cowdawg Philosophy:  Sieze the Cow! Bite the Day!
    Clever Quip:  Nobody expects the Perl Inquisition!
    Non-Perl Passion:   Dog trainer, dog agility exhibitor, brewer of fine Belgian style ales. Happiness is a warm, tired, contented dog curled up at your side and a good Belgian ale in your chalice.
[reply]
A reply falls below the community's threshold of quality. You may see it by logging in.

Back to Seekers of Perl Wisdom