12 thoughts on - CPAN Not Working, Or Is It?

• CPAN on CentOS 7 doesn’t install things in the system locations by default (and by design). This is to stop CPAN from over-writing files that actually belong to rpm packages.

  A number of things you can do. The sort of recommended way is to package the perl modules into an RPM and install them that way (so that the package managers know about them and can resolve conflicts). There are progs to do it for – look for cpanspec.

  CPAN will install the modules in ~/perl5/… by default – the “real”
  way of doing things is to @INC that location at the top of the perl script or set environment variables appropriately.

  Finally, if you must, fiddle with the CPAN configuration to install them in a system location. But be aware that things might get confused or break.

  P.

• I have found the following page to install using cpanspec, and all went well until I actually want to build the RPM’s. Doesn’t matter what I try to build I get the same problems with the man pages being missing, and nothing gets built.

  [root@lou cpanspec]# rpmbuild -ba perl-strictures.spec Executing(%prep): /bin/sh -e /var/tmp/rpm-tmp.H8RqZz
  + umask 022
  + cd /root/rpmbuild/BUILD
  + cd /root/rpmbuild/BUILD
  + rm -rf strictures-2.000006
  + /usr/bin/gzip -dc /root/rpmbuild/SOURCES/strictures-2.000006.tar.gz
  + /usr/bin/tar -xf –
  + STATUS=0
  + ‘[‘ 0 -ne 0 ‘]’
  + cd strictures-2.000006
  + /usr/bin/chmod -Rf a+rX,u+w,g-w,o-w .
  + exit 0
  Executing(%build): /bin/sh -e /var/tmp/rpm-tmp.WPzjcW
  + umask 022
  + cd /root/rpmbuild/BUILD
  + cd strictures-2.000006
  + /usr/bin/perl Makefile.PL INSTALLDIRS=vendor Checking if your kit is complete… Looks good Warning: prerequisite bareword::filehandles 0 not found. Warning: prerequisite indirect 0 not found. Warning: prerequisite multidimensional 0 not found. Writing Makefile for strictures Writing MYMETA.yml and MYMETA.json
  + make -j2
  cp lib/strictures/extra.pm blib/lib/strictures/extra.pm cp lib/strictures.pm blib/lib/strictures.pm Manifying blib/man3/strictures::extra.3pm Manifying blib/man3/strictures.3pm
  + exit 0
  Executing(%install): /bin/sh -e /var/tmp/rpm-tmp.pxcIGj
  + umask 022
  + cd /root/rpmbuild/BUILD
  + ‘[‘ /root/rpmbuild/BUILDROOT/perl-strictures-2.000006-1.el7.x86_64 ‘!=’ / ‘]’
  + rm -rf /root/rpmbuild/BUILDROOT/perl-strictures-2.000006-1.el7.x86_64
  ++ dirname /root/rpmbuild/BUILDROOT/perl-strictures-2.000006-1.el7.x86_64
  + mkdir -p /root/rpmbuild/BUILDROOT
  + mkdir /root/rpmbuild/BUILDROOT/perl-strictures-2.000006-1.el7.x86_64
  + cd strictures-2.000006
  + rm -rf /root/rpmbuild/BUILDROOT/perl-strictures-2.000006-1.el7.x86_64
  + make pure_install PERL_INSTALL_ROOT=/root/rpmbuild/BUILDROOT/perl-strictures-2.000006-1.el7.x86_64
  Manifying blib/man3/strictures::extra.3pm Manifying blib/man3/strictures.3pm Installing /root/rpmbuild/BUILDROOT/perl-strictures-2.000006-1.el7.x86_64/root/perl5/lib/perl5/strictures.pm Installing /root/rpmbuild/BUILDROOT/perl-strictures-2.000006-1.el7.x86_64/root/perl5/lib/perl5/strictures/extra.pm Installing /root/rpmbuild/BUILDROOT/perl-strictures-2.000006-1.el7.x86_64/root/perl5/man/man3/strictures::extra.3pm Installing /root/rpmbuild/BUILDROOT/perl-strictures-2.000006-1.el7.x86_64/root/perl5/man/man3/strictures.3pm
  + find /root/rpmbuild/BUILDROOT/perl-strictures-2.000006-1.el7.x86_64 -type f -name .packlist -exec rm -f ‘{}’ ‘;’
  +
  find /root/rpmbuild/BUILDROOT/perl-strictures-2.000006-1.el7.x86_64 -depth -type d -exec rmdir ‘{}’ ‘;’
  + /usr/bin/chmod -Rf a+rX,u+w,g-w,o-w /root/rpmbuild/BUILDROOT/perl-strictures-2.000006-1.el7.x86_64/root
  + /usr/lib/rpm/find-debuginfo.sh –strict-build-id -m –run-dwz –dwz-low-mem-die-limit
  10000000 –dwz-max-die-limit
  110000000 /root/rpmbuild/BUILD/strictures-2.000006
  /usr/lib/rpm/sepdebugcrcfix: Updated 0 CRC32s, 0 CRC32s did match.
  + /usr/lib/rpm/check-buildroot
  + /usr/lib/rpm/redhat/brp-compress
  + /usr/lib/rpm/redhat/brp-strip-static-archive /usr/bin/strip
  + /usr/lib/rpm/brp-python-bytecompile /usr/bin/python 1
  + /usr/lib/rpm/redhat/brp-python-hardlink
  + /usr/lib/rpm/redhat/brp-java-repack-jars Executing(%check): /bin/sh -e /var/tmp/rpm-tmp.RIav4H
  + umask 022
  + cd /root/rpmbuild/BUILD
  + cd strictures-2.000006
  + make test PERL_DL_NONLAZY=1 /usr/bin/perl “-MExtUtils::Command::MM” “-e” “test_harness(0, ‘blib/lib’, ‘blib/arch’)”
  t/*.t t/crash.t ……. ok
  t/extras.t …… ok
  t/strictures.t .. ok
  All tests successful. Files=3, TestsB, 0 wallclock secs ( 0.02 usr 0.01 sys + 0.06 cusr 0.01
  csys = 0.10 CPU)
  Result: PASS
  + exit 0
  Processing files: perl-strictures-2.000006-1.el7.noarch error: File not found by glob: /root/rpmbuild/BUILDROOT/perl-strictures-2.000006-1.el7.x86_64/usr/share/perl5/vendor_perl/*
  error: File not found by glob: /root/rpmbuild/BUILDROOT/perl-strictures-2.000006-1.el7.x86_64/usr/share/man/man3/*
  Executing(%doc): /bin/sh -e /var/tmp/rpm-tmp.QDACU6
  + umask 022
  + cd /root/rpmbuild/BUILD
  + cd strictures-2.000006
  +
  DOCDIR=/root/rpmbuild/BUILDROOT/perl-strictures-2.000006-1.el7.x86_64/usr/share/doc/perl-strictures-2.000006
  + export DOCDIR
  + /usr/bin/mkdir -p /root/rpmbuild/BUILDROOT/perl-strictures-2.000006-1.el7.x86_64/usr/share/doc/perl-strictures-2.000006
  + cp -pr Changes /root/rpmbuild/BUILDROOT/perl-strictures-2.000006-1.el7.x86_64/usr/share/doc/perl-strictures-2.000006
  + cp -pr LICENSE /root/rpmbuild/BUILDROOT/perl-strictures-2.000006-1.el7.x86_64/usr/share/doc/perl-strictures-2.000006
  + cp -pr META.json /root/rpmbuild/BUILDROOT/perl-strictures-2.000006-1.el7.x86_64/usr/share/doc/perl-strictures-2.000006
  + cp -pr README /root/rpmbuild/BUILDROOT/perl-strictures-2.000006-1.el7.x86_64/usr/share/doc/perl-strictures-2.000006
  + exit 0

  RPM build errors:
  File not found by glob: /root/rpmbuild/BUILDROOT/perl-strictures-2.000006-1.el7.x86_64/usr/share/perl5/vendor_perl/*
  File not found by glob: /root/rpmbuild/BUILDROOT/perl-strictures-2.000006-1.el7.x86_64/usr/share/man/man3/*
  [root@lou cpanspec]#

• I’m afraid I’m not expert on these things – I tend to do the naughty thing of using CPAN to install in system locations!

  But I think the .spec file generated, or the variables used for the build are not quite correct. You can see here:

  that it’s installing into …./root/perl5/ whereas here:

  it is trying to package …./usr/share/

  I think you need the help of someone who knows about .spec files!

  P.

• Hi Peter,

  Do you have any instructiions on how to do this? I realise it’s far from ideal, but I need to get this system working, and can do it on a stand alone server.

  I did wonder if maybe my rpmbuild spec is wrong as every RPM I’m trying to create is looking in the wrong location for the man pages, and the perl module files. I commented out the line for the man pages, but can’t comment out the perl modules :)

• It’s a long time since I’ve done it, but I think CPAN puts some variables in your .bashrc to configure the process. First you should run ‘perl -V’ to see if there are any entries that aren’t the system wide location – you are looking for the @INC path and/or variables like
  $PERL_LOCAL_LIB_ROOT

  If they are ok, at the CPAN prompt do ‘o conf’ to see what CPAN thinks the config is – I think the crucial options are the ones that start
  “mbuild_”.

  Ultimately you can redo the CPAN config by ‘o conf init’.

  The build and locations are influenced by some environment variables setup by rpmbuild – I have a feeling that the perl build process is using different locations to the rpmbuild so everything is getting confused.

  P.

• First, use cpanm instead of the old cpan shell:

  $ sudo yum install perl-App-cpanminus

  It has a number of advantages:

  1. It’s much smarter about chasing dependencies, which is your core problem here.

  2. It autoconfigures, not requiring all that outdated stuff about “where is your FTP program,” “what mirror should I use,” and such.

  3. It’s easy to feed it a cpanfile with a curated set of dependencies for a one-command “install everything I need here” upgrade:

  https://metacpan.org/pod/distribution/Module-CPANfile/lib/cpanfile.pod

  4. When it fails, it keeps its output in a log file that’s easy to send to mailing lists when asking for help. Hint. :)

  I try to do that, too. The claim in another reply that RPM CPAN modules and cpan- or cpanm-installed modules cannot work together is incorrect.

  What is correct is that the CentOS-provided RPMs are often sufficiently outdated that they no longer work with the latest releases that cpanm wants to download by default. The older the CentOS installation, the greater the chance of this happening, and the greater the chance that it will happen to a module that’s so deeply tied into your dependency tree that it seems to break everything.

  There are three main solutions:

  1. Tell cpanm to download an older version that works with the other RPM-installed CPAN modules:

  $ sudo cpanm Foo::Bar@1.2.3

  1b: Same thing, but in cpanfile syntax:

  requires ‘Foo::Bar’, ‘== 1.2.3′;

  cpanfile is very flexible and can be given much more granular rules; see the link above.

  2. Selectively remove CPAN modules installed via RPM that conflict and let cpanm upgrade you to the latest. This works as long as the newer modules are upwards compatible with the remaining RPM-installed CPAN modules.

  3. Use a system like App::Fatpacker or Carton to bundle your app and its dependencies into a self-contained bundle that doesn’t depend on system CPAN modules:

  https://metacpan.org/release/Carton
  https://metacpan.org/pod/App::FatPacker

  I prefer using Carton with cpanfile, but others prefer the way App::Fatpacker works.

• *snip*

  Often I end up downloading a src.rpm from Fedora for perl modules and building that.

  It means security patches are now my responsibility for it, and sometimes it has other perm module dependencies that I have to do the same thing with first, but it usually it works without too much fuss.

• Since I’m the only other person to reply, I presume you mean something I said, but I don’t think I ever said they “cannot work together” – in fact I said that personally, I use both RPM and CPAN and install into system locations.

  All I was trying to do was to explain to Gary *why* his CPAN installs weren’t working as expected, and that it is because of the possibility of CPAN over-writing RPM installed modules (and the confusion that may result), and that this was deemed to be a bad thing so the default install location was changed.

  P.

• What often happens when you have “larger” modules, they reply on libraries.  To build the perl module from source, you need to devel rpm of the library installed to link against.

  example libxml2-2.7.6-21.el6_8.1.x86_64
  libxml2-devel-2.7.6-21.el6_8.1.x86_64

  XML::Simple won’t build unless the devel is present

  CPAN isn’t real good at reporting why the build failed, just that it failed.

  What I’ve learned to  do when I have this sort of issue is to pop out of CPAN and into ~/.cpan/build.

  Locate the unpacked module and try the build manually.

  I get better errors that way.

• That’s the advice I’m responding to: you don’t need to install CPAN modules only to system locations to make Perl-based programs work. CPAN’s defaults on CentOS 7 are perfectly usable as-is, because CPAN is part of Perl, and Perl knows how to search multiple locations for a given package, including in CPAN’s default location *when* you run it as root.

  That’s only true when you run cpan or cpanm as a normal user. If you run it as root, cpanm puts modules in a directory Perl finds by default — /usr/local/share/perl5 on CentOS 7 — but which doesn’t conflict with CPAN modules installed via RPM.

  ~/perl5 isn’t in @INC by default, though, so that’s why Perl fails to find modules installed there by default.

  However, there are a bunch of ways to adjust @INC to suit local needs, so installing to ~/perl5 isn’t always a problem:

  https://perlmaven.com/how-to-change-inc-to-find-perl-modules-in-non-standard-locations

  A useful variant on one of those methods is to put lib/ in a known location relative to the main program, then use the FindBin module to adjust @INC at run time via “use lib”:

  https://perldoc.perl.org/FindBin.html

  The second class of problems I think I covered adequately in my first reply.

  That’s why you don’t want to be telling CPAN to install to system locations in the first place. RPMs and cpanm-installed libraries should never conflict on disk.

  They may conflict in their dependency graphs, of course, which again takes us back to my advice in the prior reply for managing dependencies.

• If you mean that you do that manually, you don’t have to. The “look” command in the cpan shell or the –look option to cpanm does that automatically.

  That is, it unpacks the module and drops you into a sub-shell where you can work with the module manually.

  Back when I still had to support CentOS 5, I’d occasionally have to do this to get some modules to build because they required local edits or configuration overrides that the upstream developers didn’t want to support, its Perl being deemed too old to bother with any more.

• CPAST.