moatman has asked for the wisdom of the Perl Monks concerning the following question:

I'm very new to Perl and have inherited a system that I did not setup. Some users requested some new modules installed, as well as some updated, and that's when I ran into a brick wall. Sometimes installs or updates said they were successful and they were, sometimes they'd say they went ok but not be visible or present. It turns out that the modules are installing in various locations and I don't know how to consolidate them or get it so they update and install properly.

One example is trying to update File::Spec from 3.33 to 3.40 so I can install Path::Tiny. Install of the first goes fine, says it worked, then Path::Tiny says it is still 3.33 and I need 3.40, very annoying. After some research, I found that things were being installed in various directories. I also found something called Expat that was linked into the process as well, I don't know why. Here is my @INC after trying to fix things(I tried to use local::lib to fix things, but I think the issue is more fundamental.

 %ENV:
    PERL5LIB="/usr/local/lib64/perl5"
  @INC:
    /usr/local/lib64/perl5
    /usr/local/lib64/perl5
    /usr/local/share/perl5
    /usr/lib64/perl5/vendor_perl
    /usr/share/perl5/vendor_perl
    /usr/lib64/perl5
    /usr/share/perl5

[download]

For those, as an example, File::Spec is 3.4 in /usr/lib64/local/perl5 while it's 3.33 in /usr/local/lib64/perl5(and 3.30 in /usr/share/perl5). My cpan config info looks like:

$CPAN::Config options from /usr/share/perl5/CPAN/Config.pm:
    commit             [Commit changes to disk]
    defaults           [Reload defaults from disk]
    help               [Short help about 'o conf' usage]
    init               [Interactive setting of all options]

    applypatch         []
    auto_commit        [0]
    build_cache        [100]
    build_dir          [/root/.cpan/build]
    build_dir_reuse    [0]
    build_requires_install_policy [ask/yes]
    bzip2              [/usr/bin/bzip2]
    cache_metadata     [1]
    check_sigs         [0]
    colorize_debug     undef
    colorize_output    undef
    colorize_print     undef
    colorize_warn      undef
    commandnumber_in_prompt [1]
    commands_quote     undef
    connect_to_internet_ok [1]
    cpan_home          [/root/.cpan]
    curl               [/usr/bin/curl]
    dontload_hash      undef
    dontload_list      undef
    ftp                []
    ftp_passive        [1]
    ftp_proxy          []
    ftpstats_period    undef
    ftpstats_size      undef
    getcwd             [cwd]
    gpg                [/usr/bin/gpg]
    gzip               [/bin/gzip]
    halt_on_failure    [0]
    histfile           [/root/.cpan/histfile]
    histsize           [100]
    http_proxy         []
    inactivity_timeout [0]
    index_expire       [1]
    inhibit_startup_message [0]
    keep_source_where  [/root/.cpan/sources]
    load_module_verbosity [v]
    lynx               []
    make               [/usr/bin/make]
    make_arg           []
    make_install_arg   []
    make_install_make_command [/usr/bin/make]
    makepl_arg         [EXPATLIBPATH=//data/shared/expat-2.1.0/lib EXP
+ATINCPATH=//data/shared/expat-2.1.0/include]
    mbuild_arg         []
    mbuild_install_arg []
    mbuild_install_build_command [./Build]
    mbuildpl_arg       [--installdirs site]
    ncftp              []
    ncftpget           []
    no_proxy           []
    pager              [/usr/bin/less]
    password           undef
    patch              [/usr/bin/patch]
    patches_dir        undef
    perl5lib_verbosity [v]
    prefer_external_tar undef
    prefer_installer   [MB]
    prefs_dir          [/root/.cpan/prefs]
    prerequisites_policy [ask]
    proxy_pass         undef
    proxy_user         undef
    randomize_urllist  undef
    scan_cache         [atstart]
    shell              [/bin/bash]
    show_unparsable_versions [0]
    show_upload_date   [0]
    show_zero_versions [0]
    tar                [/bin/tar]
    tar_verbosity      [v]
    term_is_latin      [1]
    term_ornaments     [1]
    test_report        [0]
    trust_test_report_history [0]
    unzip              [/usr/bin/unzip]
    urllist
    use_sqlite         [0]
    username           undef
    version_timeout    undef
    wait_list          undef
    wget               [/usr/bin/wget]
    yaml_load_code     [0]
    yaml_module        [YAML]

[download]

My Perl Config.pm(in /usr/lib64/perl5) includes the following at the end:

archlibexp => '/usr/lib64/perl5',
    archname => 'x86_64-linux-thread-multi',
    cc => 'gcc',
    d_readlink => 'define',
    d_symlink => 'define',
    dlsrc => 'dl_dlopen.xs',
    dont_use_nlink => undef,
    exe_ext => '',
    inc_version_list => '5.10.0',
    intsize => '4',
    ldlibpthname => 'LD_LIBRARY_PATH',
    libpth => '/usr/local/lib64 /lib64 /usr/lib64',
    osname => 'linux',
    osvers => '2.6.32-220.el6.x86_64',
    path_sep => ':',
    privlibexp => '/usr/share/perl5',
    scriptdir => '/usr/bin',
    sitearchexp => '/usr/local/lib64/perl5',
    sitelibexp => '/usr/local/share/perl5',
    useithreads => 'define',
    usevendorprefix => 'define',
    version => '5.10.1',

[download]

I don't know what to do at this point, I've tried various versions of editing cpan, local::lib, and the perl config file to no luck. I also don't know how Expat fits into things. Some of the times I've tried changing cpan settings, it starts using the archname and sitelib folders instead of where I tell it. I don't care which directory is used, I just want a single and cohesive set of modules that won't keep splitting up as they have. Any help would be appreciated.

Replies are listed 'Best First'.
Re: Modules being installed in different directories, causing problems.
by Tanktalus (Canon) on Dec 24, 2013 at 16:53 UTC

    That looks awfully similar to my RHEL 6 box...

    First off, you're playing with the system perl. Which may be what you want, but I always start with the suggestion not to do that. If you want a custom set of modules, I highly suggest that you use a custom install of perl. It took me a few years to come to this conclusion, but I strongly believe in it now.

    Basically, by updating modules such that "/usr/bin/perl" will load a different version of, say, File::Spec, than the distribution vendor expects, you may remove a bug that the vendor is counting on, or introduce a bug that they weren't expecting. And then system apps may fail. While this is an extremely unlikely scenario, if you are running RHEL (as opposed to CentOS), your employer may be counting on that support contract that you may be voiding, or at least making more expensive. If the system has other modules it is relying on, sometimes they break backwards-compatibility, and that runs a higher risk (though usually system tools don't rely on much that might do something like this). All in all, low likelihood, but if it does happen, the repercussions could be anywhere from support headaches to an unbootable system (likely combined with support headaches).

    Instead, by having your own copy of perl in, say, /opt/perl/bin, you know that the system tools aren't relying on any modules you might upgrade. The system tools will continue to merrily use outdated modules with exactly the feature/bug set they are expecting, while your users can put #!/opt/perl/bin/perl as their first line and get all the new features they want without impacting the running of the base operating system. This also has some other happy side effects - for example, you can upgrade to a level of perl that still continues to receive security updates (such as perl 5.16 or 5.18), again without impacting anything else. (I actually have a small array of perls installed to /opt/perl/$version, just for testing, and so I don't need to upgrade every app every time I get a new perl.)

    Failing that, the next best thing is to use your OS package manager (rpm/yum if you're on RH) to update the modules instead. If your distribution has the updated modules, this means they've allegedly tested the update and everything should work (or it should pull in the newer versions of whatever needed fixing to update that module). If you're really lucky, the new modules you want, such as Path::Tiny, are also available through this method. Then your problem should be solved. Well, other than possibly cleaning up /usr/local/lib64/perl5 and /usr/local/share/perl5.

    Hopefully that helps. I know it's not quite your question, but when faced with a similar issue, I've gone with the above, and maybe that will be an option for you, as well.

[reply]
[d/l]

      Thanks for the suggestions, I took your advice and got lucky, it was available in Yum. I am dreading the idea of having to install a second copy with the way things are set now, but I don't see my luck holding out with the all of modules we will need being in the Yum repository...

      Eventually I will have to add our own copy, I can definitely see the wisdom in it and was very close to doing it in this last time. It really opened my eyes, I had no idea it was just haphazardly throwing things wherever it pleased, being in full control of installs will be very nice.

      Thanks again, and to everyone else who replied as well.

[reply]
Re: Modules being installed in different directories, causing problems.
by karlgoethebier (Abbot) on Dec 24, 2013 at 20:21 UTC
[reply]
Re: Modules being installed in different directories, causing problems.
by Anonymous Monk on Dec 26, 2013 at 15:43 UTC

    I second the advice not to mess with the system Perl. But it's your system not mine. I believe you can get the older copies of modules at least somewhat cleaned out by configuring the install arguments. Something like

    cpan> o conf make_install_arg UNINST=1
cpan> o conf mbuild_install_arg uninst=1
cpan> o conf commit

    may do what you want. I am unsure what will happen if the new kit does not contain all the modules that the old kit contains.

[reply]

Back to Seekers of Perl Wisdom