From frederik@ofb.net

Created by frederik@ofb.net

This is a follow-up to an earlier bug report, which complains about
the fact that users see an uninformative error message "loadable
library and perl binaries are mismatched", after a Linux distribution
upgrade, if they have installed Perl modules locally e.g. using the
'cpan' tool.

https://rt.perl.org/Public/Bug/Display.html?id=133440

Thanks to everyone who responded to the original. I guess we're
waiting for key developers to give us some guidance on improving the
error message and documentation patches I sent, but looking back over
these emails, there are a few things that I'm still confused about and
I thought maybe we could make some progress if I tried to resolve
those deficits in my understanding.

These mostly have to do with the toolchain, 'cpan'/'cpanm', and
probably ExtUtils​::MakeMaker and other modules, so I'm submitting a
new bug report which I hope can focus on the toolchain aspect of this
problem. I've never tried to contribute a module to CPAN so I am
unfamiliar with how to submit bugs against toolchain components. If
this bug should be submitted elsewhere or against certain modules,
then please let me know. I'm pasting some of the original bug thread
for background below, and then I follow that with a few comments.

----------------------------------------------------------------

Date​: Fri, 10 Aug 2018 13​:18​:56 -0700
From​: Andy Dougherty via RT <perlbug-followup@​perl.org>

I'm not sure why you have Compress​::Raw​::Zlib installed locally, since
it has been bundled with perl since version 5.9.4. [...]

Date​: Tue, 14 Aug 2018 20​:27​:23 -0400
From​: Dan Book <grinnz@​gmail.com>

These are good ideas. The fundamental issue though is that modules you
installed for one major version of Perl must always be installed again for
another, and users don't tend to expect this whether they use local​::lib or
not, it will always be a problem if you install modules without using your
package manager in a Perl managed by your package manager.

Date​: Sat, 18 Aug 2018 23​:27​:46 -0700
From​: Dan Book via RT <perlbug-followup@​perl.org>

Thanks for your reply. While trying to downgrade my system (debugging
another issue) I discovered a possible reason why I have problematic
binary modules in my home directory which are also in Perl core
(causing cpan to break when I upgrade Perl). The reason appears to be
that the "recompile" cpan command reinstalls modules which I had
removed earlier using 'cpanm'.
[...]

These are dual-life modules; it is expected and often desired to install
them a second time in site or vendor libs to upgrade them from the core
module version. Since Perl 5.12, site and vendor libs take precedence
in @​INC for that reason. local​::lib of course takes precedence over all
standard lib directories. [...]

Date​: Tue, 21 Aug 2018 16​:43​:58 -0700
From​: frederik@​ofb.net

These are dual-life modules; [...]

You're saying that these modules are purposefully installed by 'cpan'
even when compatible versions already exist in 'core'?

I guess not everyone expects this, because when I first submitted this
bug report I got a response from Andy Dougherty saying "I'm not sure
why you have Compress​::Raw​::Zlib installed locally, since it has been
bundled with perl since version 5.9.4." And I have in my shell history
that I uninstalled it, while now it is back in ~/.local. Although when
I removed it again and re-ran 'cpan -r', it didn't reappear, so I'm
not entirely sure what's happening.

Date​: Tue, 21 Aug 2018 17​:00​:08 -0700
From​: Dan Book via RT <perlbug-followup@​perl.org>

That is correct. His response seemed to account for this possibility but
was asking why you had installed a newer version in a local lib without the
use of version specific directories, which could be considered a deficiency
in the toolchain. Regardless, upgrades to dual-life modules are installed
in sitelib or local libs very commonly, this is the reason they are
available from CPAN. I can't comment on how CPAN.pm's recompile function
interacts with dual-life modules or local libs.

Date​: Tue, 18 Sep 2018 10​:43​:27 +0100
From​: Dave Mitchell <davem@​iabyn.com>

[...]
The particular scenario you encountered seems to me to be relatively rare.
It required the following combination of circumstances​:

1) You were using the OS's perl installation.
2) You didn't use the OS's packing system to add extra CPAN modules​:
  for example on Fedora to install the Time​::ParseDate module,
  I would install the perl-Time-ParseDate RPM provided by Fedora.
3) You didn't use cpan or similar in a way that installs the extra packages
  as part of the perl installation which the cpan tool is a part of.
4) You used the third-party local​::lib tool install the extra CPAN modules
  under your home directory, which doesn't install them in
  version-specific paths.

----------------

My comments​:

1. In using 'cpanm' and local​::lib, I thought I was doing the
"standard thing", for example cpanm mentions local​::lib under the
documentation for the "-l, --local-lib" flag. But other people seem to
be installing modules in "version-specific directories", which I don't
even know how to do. It doesn't seem to be the default, since I just
ran 'cpan' in a new user account and after hitting 'enter' at every
prompt and typing 'install List​::BinarySearch', I found that the XS
module was installed here​:

~/perl5/lib/perl5/x86_64-linux-thread-multi/auto/List/BinarySearch/XS/XS.so

I assume this location is not version-specific, since it has no
version number, just the architecture. How does someone (like Dave?)
install a module like List​::BinarySearch without encountering the
above scenario, which he describes as "relatively rare"? (I don't
think my distribution has List​::BinarySearch pre-packaged, but let's
assume that it doesn't)

2. I think people were taken aback when I mentioned that I have common
binary modules like Compress​::Raw​::Zlib installed in $HOME. I later
learned this is something that 'cpan' and 'cpanm' do automatically
(see "dual-life modules" above). (Dan Book said "His response seemed
to account for this possibility" but I'm not sure what was meant by
that...)

How are users notified of the fact that system-level modules are being
reinstalled locally, turned into "dual-life modules" as it were? Is
this in the documentation? I see the term "dual-life" appearing in the
cpanm manual page, but it is not defined, neither are neighboring
terms like "shadow files" defined​:

  --uninst-shadows
  Uninstalls the shadow files of the distribution that you're
  installing. This eliminates the confusion if you're trying to
  install core (dual-life) modules from CPAN against perl 5.10 or
  older, or modules that used to be XS-based but switched to pure
  perl at some version.

How are other people (like Andy Dougherty?) avoiding 'cpan' install
actions that pull in binary dependencies like Compress​::Raw​::Zlib? I'm
guessing he didn't just "hit enter" at one of the prompts, like I did?

3. My own reason for wanting things to be installed in my home
directory is so that I can use some custom scripts easily on systems
where I don't have administrative access, just by copying everything
over with my shell config. My scripts are pretty simple, I'm not
trying to deploy a website or anything so I'm not sure that including
a separate build of Perl is warranted (although I see that libperl is
only 3.3M...).

Perhaps I'm taking the wrong approach, maybe I should not be using the
'cpan' tool in my use case - namely "unprivileged user with simple
utility scripts that have a few external dependencies". However, I'm
guessing it is a pretty common case, and I realized that the problem
I'm running into with the confusing "binaries mismatched" error
message is something that I could completely avoid if I could tell
'cpan' to refrain from installing what Dan called "dual-life modules",
in other words to stick with installing only modules that are not
already installed system-wide (or elsewhere in PERL5LIB).

Further, when there is an option to install a binary version of a
module, it would be nice to be able to tell 'cpan'/'cpanm' that I am
only interested in the pure-Perl implementation, or at least for it to
install the binary component in such a way that Perl can automatically
fall back on the pure-Perl version of the module, when I find myself
using my scripts on a machine with a different architecture or Perl
version or whatever else would make it impossible to employ the binary
module. In rare cases where I want to depend on a binary module, I
would probably do it by installing the distribution package for that
module, since there is a big overlap between modules which have XS
code and modules which are available in distribution-specific
packages. Basically, a big feature of Perl is backwards compatibility,
and it seems like I should be able to assemble a collection of
modules, using automatic tools like 'cpan', in such a way that they
continue to run correctly on a wide variety of systems.

It seems to me that there are a few bugs or potential areas for
improvement here. Is anyone else concerned about these things, what is
the status, and am I missing something?

Thank you,

Frederick

Flags:
    category=install
    severity=medium

Site configuration information for perl 5.28.0:

Configured by builduser at Wed Aug  1 10:43:08 CEST 2018.

Summary of my perl5 (revision 5 version 28 subversion 0) configuration:
   
  Platform:
    osname=linux
    osvers=4.17.11-arch1
    archname=x86_64-linux-thread-multi
    uname='linux flo-64s 4.17.11-arch1 #1 smp preempt sun jul 29 10:11:16 utc 2018 x86_64 gnulinux '
    config_args='-des -Dusethreads -Duseshrplib -Doptimize=-march=x86-64 -mtune=generic -O2 -pipe -fstack-protector-strong -fno-plt -Dprefix=/usr -Dvendorprefix=/usr -Dprivlib=/usr/share/perl5/core_perl -Darchlib=/usr/lib/perl5/5.28/core_perl -Dsitelib=/usr/share/perl5/site_perl -Dsitearch=/usr/lib/perl5/5.28/site_perl -Dvendorlib=/usr/share/perl5/vendor_perl -Dvendorarch=/usr/lib/perl5/5.28/vendor_perl -Dscriptdir=/usr/bin/core_perl -Dsitescript=/usr/bin/site_perl -Dvendorscript=/usr/bin/vendor_perl -Dinc_version_list=none -Dman1ext=1perl -Dman3ext=3perl -Dcccdlflags='-fPIC' -Dlddlflags=-shared -Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now -Dldflags=-Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now'
    hint=recommended
    useposix=true
    d_sigaction=define
    useithreads=define
    usemultiplicity=define
    use64bitint=define
    use64bitall=define
    uselongdouble=undef
    usemymalloc=n
    default_inc_excludes_dot=define
    bincompat5005=undef
  Compiler:
    cc='cc'
    ccflags ='-D_REENTRANT -D_GNU_SOURCE -fwrapv -fno-strict-aliasing -pipe -fstack-protector-strong -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64'
    optimize='-march=x86-64 -mtune=generic -O2 -pipe -fstack-protector-strong -fno-plt'
    cppflags='-D_REENTRANT -D_GNU_SOURCE -fwrapv -fno-strict-aliasing -pipe -fstack-protector-strong -I/usr/local/include'
    ccversion=''
    gccversion='8.1.1 20180531'
    gccosandvers=''
    intsize=4
    longsize=8
    ptrsize=8
    doublesize=8
    byteorder=12345678
    doublekind=3
    d_longlong=define
    longlongsize=8
    d_longdbl=define
    longdblsize=16
    longdblkind=3
    ivtype='long'
    ivsize=8
    nvtype='double'
    nvsize=8
    Off_t='off_t'
    lseeksize=8
    alignbytes=8
    prototype=define
  Linker and Libraries:
    ld='cc'
    ldflags ='-Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now -fstack-protector-strong -L/usr/local/lib'
    libpth=/usr/local/lib /usr/lib/gcc/x86_64-pc-linux-gnu/8.1.1/include-fixed /usr/lib /lib/../lib /usr/lib/../lib /lib /lib64 /usr/lib64
    libs=-lpthread -lgdbm -ldb -ldl -lm -lcrypt -lutil -lc -lgdbm_compat
    perllibs=-lpthread -ldl -lm -lcrypt -lutil -lc
    libc=libc-2.27.so
    so=so
    useshrplib=true
    libperl=libperl.so
    gnulibc_version='2.27'
  Dynamic Linking:
    dlsrc=dl_dlopen.xs
    dlext=so
    d_dlsymun=undef
    ccdlflags='-Wl,-E -Wl,-rpath,/usr/lib/perl5/5.28/core_perl/CORE'
    cccdlflags='-fPIC'
    lddlflags='-shared -Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now -L/usr/local/lib -fstack-protector-strong'



@INC for perl 5.28.0:
    /home/frederik/scripts-misc/perl
    /home/frederik/.local/lib/perl5/5.28.0/x86_64-linux-thread-multi
    /home/frederik/.local/lib/perl5/5.28.0
    /home/frederik/.local/lib/perl5/x86_64-linux-thread-multi
    /home/frederik/.local/lib/perl5
    /usr/lib/perl5/5.28/site_perl
    /usr/share/perl5/site_perl
    /usr/lib/perl5/5.28/vendor_perl
    /usr/share/perl5/vendor_perl
    /usr/lib/perl5/5.28/core_perl
    /usr/share/perl5/core_perl


Environment for perl 5.28.0:
    HOME=/home/frederik
    LANG=en_US.UTF-8
    LANGUAGE (unset)
    LD_LIBRARY_PATH=/home/frederik/.local/arch/x86_64/lib:/home/frederik/.local/lib:/usr/local/lib
    LOGDIR (unset)
    PATH=/home/frederik/.local/bin:/home/frederik/projects/mailproc:/home/frederik/scripts-misc:/home/frederik/.local/arch/x86_64/bin:/usr/bin/core_perl:/usr/bin/vendor_perl:/usr/bin/site_perl:/usr/local/bin:/usr/local/sbin:/usr/bin
    PERL5LIB=/home/frederik/scripts-misc/perl:/home/frederik/.local/lib/perl5:
    PERL_BADLANG (unset)
    PERL_LOCAL_LIB_ROOT=/home/frederik/.local/:/home/frederik/.local/:/home/frederik/.local/
    PERL_MB_OPT=--install_base "/home/frederik/.local/"
    PERL_MM_OPT=INSTALL_BASE=/home/frederik/.local/
    SHELL=/bin/zsh

From @iabyn

On Sat, Oct 13, 2018 at 12​:15​:09PM -0700, (via RT) wrote​:

1. In using 'cpanm' and local​::lib, I thought I was doing the
"standard thing", for example cpanm mentions local​::lib under the
documentation for the "-l, --local-lib" flag. But other people seem to
be installing modules in "version-specific directories", which I don't
even know how to do. It doesn't seem to be the default, since I just
ran 'cpan' in a new user account and after hitting 'enter' at every
prompt and typing 'install List​::BinarySearch', I found that the XS
module was installed here​:

~/perl5/lib/perl5/x86_64-linux-thread-multi/auto/List/BinarySearch/XS/XS.so

I assume this location is not version-specific, since it has no
version number, just the architecture. How does someone (like Dave?)
install a module like List​::BinarySearch without encountering the
above scenario, which he describes as "relatively rare"? (I don't
think my distribution has List​::BinarySearch pre-packaged, but let's
assume that it doesn't)

A perl configured and built using default options *will* use
version-specific paths. Here's a simple test I did just now​:

$ tar xfz ~/perl5/tarballs/perl-5.28.0.tar.gz
$ cd perl-5.28.0/
$ PATH=/bin​:/usr/bin sh Configure -des -Dprefix=/home/davem/tmp/foo/perl && TEST_JOBS=16 HARNESS_OPTIONS=j16 make -j 16 test_harness && make -j 16 install
$ cd ..; $ rm -rf perl-5.28.0
$ cd /home/davem/tmp/foo
$ perl/bin/cpan
cpan[1]> install List​::BinarySearch
Would you like to install List​::BinarySearch​::XS? [y]
$ find . |grep BinarySearch
./perl/lib/site_perl/5.28.0/x86_64-linux/auto/List/BinarySearch
./perl/lib/site_perl/5.28.0/x86_64-linux/auto/List/BinarySearch/XS
./perl/lib/site_perl/5.28.0/x86_64-linux/auto/List/BinarySearch/XS/XS.so
./perl/lib/site_perl/5.28.0/x86_64-linux/auto/List/BinarySearch/XS/.packlist
./perl/lib/site_perl/5.28.0/x86_64-linux/auto/List/BinarySearch/.packlist
./perl/lib/site_perl/5.28.0/x86_64-linux/List/BinarySearch
./perl/lib/site_perl/5.28.0/x86_64-linux/List/BinarySearch/XS.pm
./perl/lib/site_perl/5.28.0/List/BinarySearch.pm
./perl/lib/site_perl/5.28.0/List/BinarySearch
./perl/lib/site_perl/5.28.0/List/BinarySearch/PP.pm
./perl/man/man3/List​::BinarySearch.3
./perl/man/man3/List​::BinarySearch​::XS.3
./perl/man/man3/List​::BinarySearch​::PP.3

Please look carefully at the above, and bear it very keenly in mind for
any further discussion. If that doesn't convince you that perl does in
indeed use version-specific paths *by default*, then you'll have to be
very clear and specific about what your doubts are.

2. I think people were taken aback when I mentioned that I have common
binary modules like Compress​::Raw​::Zlib installed in $HOME. I later
learned this is something that 'cpan' and 'cpanm' do automatically

No, by default cpan etc will try to install under the site_perl directory
of wherever perl was installed, unless you tell it otherwise, e.g. with
options at perl build time, or by using an external tool like local​::lib
to set some environment variables which tells cpan to install somewhere
else.

How are users notified of the fact that system-level modules are being
reinstalled locally, turned into "dual-life modules" as it were?

Users will only get this behaviour if they request it.

The term 'dual-life' is usually used (by us at least) to refer to
something different - where a module is both bundled with perl and
available (possibly in a newer version) on CPAN. It doesn't (very much)
relate to where the module gets installed).

How are other people (like Andy Dougherty?) avoiding 'cpan' install
actions that pull in binary dependencies like Compress​::Raw​::Zlib? I'm
guessing he didn't just "hit enter" at one of the prompts, like I did?

Again, this just doesn't normally occur with a default installation.

Perhaps I'm taking the wrong approach, maybe I should not be using the
'cpan' tool in my use case - namely "unprivileged user with simple
utility scripts that have a few external dependencies". However, I'm
guessing it is a pretty common case, and I realized that the problem
I'm running into with the confusing "binaries mismatched" error
message is something that I could completely avoid if I could tell
'cpan' to refrain from installing what Dan called "dual-life modules",
in other words to stick with installing only modules that are not
already installed system-wide (or elsewhere in PERL5LIB).

No, what you really want to do is, if installing under your home
directory, install version-sensitive files under version-specific paths.
This appears to be a infelicity in the current local​::lib tool. I don't
know a lot about local​::lib, and I'm not a "toolchain guy", so I don't
know whether there's a good reason why local​::lib does things the way it
does or whether it can be altered / extended to include versions in paths.

Further, when there is an option to install a binary version of a
module, it would be nice to be able to tell 'cpan'/'cpanm' that I am
only interested in the pure-Perl implementation, or at least for it to
install the binary component in such a way that Perl can automatically
fall back on the pure-Perl version of the module, when I find myself
using my scripts on a machine with a different architecture or Perl
version or whatever else would make it impossible to employ the binary
module. In rare cases where I want to depend on a binary module, I
would probably do it by installing the distribution package for that
module, since there is a big overlap between modules which have XS
code and modules which are available in distribution-specific
packages. Basically, a big feature of Perl is backwards compatibility,
and it seems like I should be able to assemble a collection of
modules, using automatic tools like 'cpan', in such a way that they
continue to run correctly on a wide variety of systems.

I think such functionality would have to be done by the distribution
itself on a case-by-case basis.

It seems to me that there are a few bugs or potential areas for
improvement here. Is anyone else concerned about these things, what is
the status, and am I missing something?

My thoughts​:

* The situation is not ideal, but
* fixes are not easy​: this whole area is complex (and not one I
  understand well)

--
Technology is dominated by two types of people​: those who understand what
they do not manage, and those who manage what they do not understand.

The RT System itself - Status changed from 'new' to 'open'

From frederik@ofb.net

A perl configured and built using default options *will* use
version-specific paths. Here's a simple test I did just now​:

$ tar xfz ~/perl5/tarballs/perl-5.28.0.tar.gz
...

Thanks Dave for doing this test (and including the commands), I will
do some investigation and try to figure out what is giving us
different results before I reply to the rest of your message.

From @doughera88

On Sat, Oct 13, 2018 at 12​:15​:09PM -0700, (via RT) wrote​:

# New Ticket Created by
# Please include the string​: [perl #133587]
# in the subject line of all future correspondence about this issue.
# <URL​: https://rt-archive.perl.org/perl5/Ticket/Display.html?id=133587 >

[Please describe your issue here]

This is a follow-up to an earlier bug report, which complains about
the fact that users see an uninformative error message "loadable
library and perl binaries are mismatched", after a Linux distribution
upgrade, if they have installed Perl modules locally e.g. using the
'cpan' tool.

[Incidentally, this issue is not limited to Linux. If I recall correctly,
the safety check and corresponding error message were contributed by a
Windows user based on his own experience.]

These mostly have to do with the toolchain, 'cpan'/'cpanm', and
probably ExtUtils​::MakeMaker and other modules, so I'm submitting a
new bug report which I hope can focus on the toolchain aspect of this
problem.

The central issue is that if you expect to encounter multiple versions of
perl, then version-specific files (typically shared libraries) should be
stored in version-specific directories. The default built-in directory
hierarchies (privlib, vendorlib, and sitelib) do that. The core pragma
lib.pm is supposed to make it easy to use additional hierarchies with
similar versioned configurations.

One problem is that if the end user does not have write access to the
standard perl directories, there is no obvious easy tool to create
an appropriate private tree with version-specific subdirectories.
Running ExtUtils​::MakeMaker with options such as

  perl Makefile.PL INSTALLDIRS=perl PREFIX=$HOME/perl

is one way to do it, but it depends on how the user wants to organize
things.

On the surface, supporting version-specific directories within local​::lib
seems like a reasonable feature request. I've never used it, however,
so I don't know if that would cause other problems. It also might
be made easier by a new MakeMaker option (sort of like INSTALL_BASE,
but including versions in the library directories). That's another
reasonable-looking feature request for the ExtUtils​::MakeMaker module.

--
  Andy Dougherty doughera@​lafayette.edu

From @Leont

On Mon, Oct 15, 2018 at 1​:39 PM Dave Mitchell <davem@​iabyn.com> wrote​:

No, what you really want to do is, if installing under your home
directory, install version-sensitive files under version-specific paths.
This appears to be a infelicity in the current local​::lib tool. I don't
know a lot about local​::lib, and I'm not a "toolchain guy", so I don't
know whether there's a good reason why local​::lib does things the way it
does or whether it can be altered / extended to include versions in paths.

local​::lib doesn't support version/configuration specific paths
because PERL5LIB doesn't support such a thing. Short of horrible hacks
involving putting a coderef in @​INC (which causes issues elsewhere) I
can't see a solution based on the current primitives.

Leon

From @eserte

Leon Timmermans <fawaka@​gmail.com> writes​:

On Mon, Oct 15, 2018 at 1​:39 PM Dave Mitchell <davem@​iabyn.com> wrote​:

No, what you really want to do is, if installing under your home
directory, install version-sensitive files under version-specific paths.
This appears to be a infelicity in the current local​::lib tool. I don't
know a lot about local​::lib, and I'm not a "toolchain guy", so I don't
know whether there's a good reason why local​::lib does things the way it
does or whether it can be altered / extended to include versions in paths.

local​::lib doesn't support version/configuration specific paths
because PERL5LIB doesn't support such a thing.

Hmmm. "perldoc perlrun" says​:

PERL5LIB [...] Any architecture-specific and version-specific
  directories, such as version/archname/, version/, or
  archname/ under the specified locations are automatically
  included if they exist

So PERL5LIB does the right thing. Unfortunately EUMM's INSTALL_BASE does
not support this.

Regards,
  Slaven

--
Slaven Rezic - slaven <at> rezic <dot> de

  Berlin Perl Mongers - http​://berlin.pm.org

From @Grinnz

On Mon, 15 Oct 2018 13​:23​:29 -0700, slaven@​rezic.de wrote​:

Leon Timmermans <fawaka@​gmail.com> writes​:

On Mon, Oct 15, 2018 at 1​:39 PM Dave Mitchell <davem@​iabyn.com>
wrote​:

No, what you really want to do is, if installing under your home
directory, install version-sensitive files under version-specific
paths.
This appears to be a infelicity in the current local​::lib tool. I
don't
know a lot about local​::lib, and I'm not a "toolchain guy", so I
don't
know whether there's a good reason why local​::lib does things the
way it
does or whether it can be altered / extended to include versions in
paths.

local​::lib doesn't support version/configuration specific paths
because PERL5LIB doesn't support such a thing.

Hmmm. "perldoc perlrun" says​:

PERL5LIB [...] Any architecture-specific and version-specific
directories, such as version/archname/, version/, or
archname/ under the specified locations are
automatically
included if they exist

So PERL5LIB does the right thing. Unfortunately EUMM's INSTALL_BASE
does
not support this.

This documentation only mentions 'version-specific' since Perl 5.18.0. The documentation for https://perldoc.pl/lib mentions it since Perl 5.8.9. I'm not sure if this reflects when the feature was actually present, but local​::lib does need to support older Perls.

From @eserte

"Dan Book via RT" <perlbug-followup@​perl.org> writes​:

On Mon, 15 Oct 2018 13​:23​:29 -0700, slaven@​rezic.de wrote​:

Leon Timmermans <fawaka@​gmail.com> writes​:

On Mon, Oct 15, 2018 at 1​:39 PM Dave Mitchell <davem@​iabyn.com>
wrote​:

No, what you really want to do is, if installing under your home
directory, install version-sensitive files under version-specific
paths.
This appears to be a infelicity in the current local​::lib tool. I
don't
know a lot about local​::lib, and I'm not a "toolchain guy", so I
don't
know whether there's a good reason why local​::lib does things the
way it
does or whether it can be altered / extended to include versions in
paths.

local​::lib doesn't support version/configuration specific paths
because PERL5LIB doesn't support such a thing.

Hmmm. "perldoc perlrun" says​:

PERL5LIB [...] Any architecture-specific and version-specific
directories, such as version/archname/, version/, or
archname/ under the specified locations are
automatically
included if they exist

So PERL5LIB does the right thing. Unfortunately EUMM's INSTALL_BASE
does
not support this.

This documentation only mentions 'version-specific' since Perl 5.18.0.
The documentation for https://perldoc.pl/lib mentions it since Perl
5.8.9. I'm not sure if this reflects when the feature was actually
present, but local​::lib does need to support older Perls.

I still assert that it's not local​::lib which is doing things wrong, but
EUMM (and probably MB), because by using INSTALL_BASE things don't end
up in version-specific directories if it is needed. Maybe this could be
fixed. If this could be fixed, then local​::lib could simply raise the
EUMM (and maybe MB) prereq versions (as it already does nowadays).

BTW, even perl 5.8.1 supports version-specific directories. I don't have
older perls for experimenting.

Regards,
  Slaven

--
Slaven Rezic - slaven <at> rezic <dot> de
  BBBike - route planner for cyclists in Berlin
  WWW version​: http​://www.bbbike.de
  Perl/Tk version for Unix and Windows​: http​://bbbike.sourceforge.net

From @haarg

On Mon, Oct 15, 2018 at 1​:39 PM Dave Mitchell <davem@​iabyn.com> wrote​:

On Sat, Oct 13, 2018 at 12​:15​:09PM -0700, (via RT) wrote​:

1. In using 'cpanm' and local​::lib, I thought I was doing the
"standard thing", for example cpanm mentions local​::lib under the
documentation for the "-l, --local-lib" flag. But other people seem to
be installing modules in "version-specific directories", which I don't
even know how to do. It doesn't seem to be the default, since I just
ran 'cpan' in a new user account and after hitting 'enter' at every
prompt and typing 'install List​::BinarySearch', I found that the XS
module was installed here​:

~/perl5/lib/perl5/x86_64-linux-thread-multi/auto/List/BinarySearch/XS/XS.so

I assume this location is not version-specific, since it has no
version number, just the architecture. How does someone (like Dave?)
install a module like List​::BinarySearch without encountering the
above scenario, which he describes as "relatively rare"? (I don't
think my distribution has List​::BinarySearch pre-packaged, but let's
assume that it doesn't)

A perl configured and built using default options *will* use
version-specific paths. Here's a simple test I did just now​:

$ tar xfz ~/perl5/tarballs/perl-5.28.0.tar.gz
$ cd perl-5.28.0/
$ PATH=/bin​:/usr/bin sh Configure -des -Dprefix=/home/davem/tmp/foo/perl && TEST_JOBS=16 HARNESS_OPTIONS=j16 make -j 16 test_harness && make -j 16 install
$ cd ..; $ rm -rf perl-5.28.0
$ cd /home/davem/tmp/foo
$ perl/bin/cpan
cpan[1]> install List​::BinarySearch
Would you like to install List​::BinarySearch​::XS? [y]
$ find . |grep BinarySearch
./perl/lib/site_perl/5.28.0/x86_64-linux/auto/List/BinarySearch
./perl/lib/site_perl/5.28.0/x86_64-linux/auto/List/BinarySearch/XS
./perl/lib/site_perl/5.28.0/x86_64-linux/auto/List/BinarySearch/XS/XS.so
./perl/lib/site_perl/5.28.0/x86_64-linux/auto/List/BinarySearch/XS/.packlist
./perl/lib/site_perl/5.28.0/x86_64-linux/auto/List/BinarySearch/.packlist
./perl/lib/site_perl/5.28.0/x86_64-linux/List/BinarySearch
./perl/lib/site_perl/5.28.0/x86_64-linux/List/BinarySearch/XS.pm
./perl/lib/site_perl/5.28.0/List/BinarySearch.pm
./perl/lib/site_perl/5.28.0/List/BinarySearch
./perl/lib/site_perl/5.28.0/List/BinarySearch/PP.pm
./perl/man/man3/List​::BinarySearch.3
./perl/man/man3/List​::BinarySearch​::XS.3
./perl/man/man3/List​::BinarySearch​::PP.3

Please look carefully at the above, and bear it very keenly in mind for
any further discussion. If that doesn't convince you that perl does in
indeed use version-specific paths *by default*, then you'll have to be
very clear and specific about what your doubts are.

2. I think people were taken aback when I mentioned that I have common
binary modules like Compress​::Raw​::Zlib installed in $HOME. I later
learned this is something that 'cpan' and 'cpanm' do automatically

No, by default cpan etc will try to install under the site_perl directory
of wherever perl was installed, unless you tell it otherwise, e.g. with
options at perl build time, or by using an external tool like local​::lib
to set some environment variables which tells cpan to install somewhere
else.

This is true if you have permissions to install in site_perl. But if
you try to install modules using system perl without running as root,
you probably won't have access to do that.

In that case, both CPAN.pm and cpanm will default to using local​::lib
and installing into ~/perl5, using ExtUtils​::MakeMaker's INSTALL_BASE
option and Module​::Build's --install_base option. Those options don't
use versioned paths.

How are users notified of the fact that system-level modules are being
reinstalled locally, turned into "dual-life modules" as it were?

Users will only get this behaviour if they request it.

The term 'dual-life' is usually used (by us at least) to refer to
something different - where a module is both bundled with perl and
available (possibly in a newer version) on CPAN. It doesn't (very much)
relate to where the module gets installed).

How are other people (like Andy Dougherty?) avoiding 'cpan' install
actions that pull in binary dependencies like Compress​::Raw​::Zlib? I'm
guessing he didn't just "hit enter" at one of the prompts, like I did?

Again, this just doesn't normally occur with a default installation.

Perhaps I'm taking the wrong approach, maybe I should not be using the
'cpan' tool in my use case - namely "unprivileged user with simple
utility scripts that have a few external dependencies". However, I'm
guessing it is a pretty common case, and I realized that the problem
I'm running into with the confusing "binaries mismatched" error
message is something that I could completely avoid if I could tell
'cpan' to refrain from installing what Dan called "dual-life modules",
in other words to stick with installing only modules that are not
already installed system-wide (or elsewhere in PERL5LIB).

No, what you really want to do is, if installing under your home
directory, install version-sensitive files under version-specific paths.
This appears to be a infelicity in the current local​::lib tool. I don't
know a lot about local​::lib, and I'm not a "toolchain guy", so I don't
know whether there's a good reason why local​::lib does things the way it
does or whether it can be altered / extended to include versions in paths.

local​::lib is using the options provided by ExtUtils​::MakeMaker and
Module​::Build. I've worked in the past on using additional options to
force installing into versioned directories, but didn't end up
finishing the work. I had found other options for myself, and nobody
else pushed for fixing the issue until now, so I hadn't gotten back to
it.

Further, when there is an option to install a binary version of a
module, it would be nice to be able to tell 'cpan'/'cpanm' that I am
only interested in the pure-Perl implementation, or at least for it to
install the binary component in such a way that Perl can automatically
fall back on the pure-Perl version of the module, when I find myself
using my scripts on a machine with a different architecture or Perl
version or whatever else would make it impossible to employ the binary
module. In rare cases where I want to depend on a binary module, I
would probably do it by installing the distribution package for that
module, since there is a big overlap between modules which have XS
code and modules which are available in distribution-specific
packages. Basically, a big feature of Perl is backwards compatibility,
and it seems like I should be able to assemble a collection of
modules, using automatic tools like 'cpan', in such a way that they
continue to run correctly on a wide variety of systems.

I think such functionality would have to be done by the distribution
itself on a case-by-case basis.

It seems to me that there are a few bugs or potential areas for
improvement here. Is anyone else concerned about these things, what is
the status, and am I missing something?

My thoughts​:

* The situation is not ideal, but
* fixes are not easy​: this whole area is complex (and not one I
understand well)

--
Technology is dominated by two types of people​: those who understand what
they do not manage, and those who manage what they do not understand.

From @haarg

On Mon, Oct 15, 2018 at 10​:33 PM Dan Book via RT
<perlbug-followup@​perl.org> wrote​:

On Mon, 15 Oct 2018 13​:23​:29 -0700, slaven@​rezic.de wrote​:

Leon Timmermans <fawaka@​gmail.com> writes​:

On Mon, Oct 15, 2018 at 1​:39 PM Dave Mitchell <davem@​iabyn.com>
wrote​:

No, what you really want to do is, if installing under your home
directory, install version-sensitive files under version-specific
paths.
This appears to be a infelicity in the current local​::lib tool. I
don't
know a lot about local​::lib, and I'm not a "toolchain guy", so I
don't
know whether there's a good reason why local​::lib does things the
way it
does or whether it can be altered / extended to include versions in
paths.

local​::lib doesn't support version/configuration specific paths
because PERL5LIB doesn't support such a thing.

Hmmm. "perldoc perlrun" says​:

PERL5LIB [...] Any architecture-specific and version-specific
directories, such as version/archname/, version/, or
archname/ under the specified locations are
automatically
included if they exist

So PERL5LIB does the right thing. Unfortunately EUMM's INSTALL_BASE
does
not support this.

This documentation only mentions 'version-specific' since Perl 5.18.0. The documentation for https://perldoc.pl/lib mentions it since Perl 5.8.9. I'm not sure if this reflects when the feature was actually present, but local​::lib does need to support older Perls.

Automatic support for versioned library paths in both PERL5LIB and
lib.pm has existed since at least 5.003_01.

---
via perlbug​: queue​: perl5 status​: open
https://rt-archive.perl.org/perl5/Ticket/Display.html?id=133587

From frederik@ofb.net

Yesterday I wrote "I will do some investigation and try to figure out
what is giving us different results before I reply to the rest of your
message." It looks like Graham Knop saved me the trouble - thank you!

Date​: Tue, 16 Oct 2018 04​:15​:50 -0700
From​: Graham Knop via RT <perlbug-followup@​perl.org>

This is true if you have permissions to install in site_perl. But if
you try to install modules using system perl without running as root,
you probably won't have access to do that.

In that case, both CPAN.pm and cpanm will default to using local​::lib
and installing into ~/perl5, using ExtUtils​::MakeMaker's INSTALL_BASE
option and Module​::Build's --install_base option. Those options don't
use versioned paths.

From frederik@ofb.net

Thank you Graham for figuring out the reason for the behavior I'm
experiencing, and why it didn't match Dave's test-case.

I guess a summary of this thread is that most Perl developers either
(1) don't use Perl on systems where they don't have root access, or
(2) compile their own Perl and install it somewhere in ~/ in such
cases.

That this would be necessary seems odd to me, for example my shell
configuration is portable across multiple non-privileged acounts
without having to recompile my shell for different architectures and
distributions.

Of course, it is not necessary if I don't use 'cpan'/'cpanm', and if I
stick to installing (pure-Perl) modules by hand.

My question would be if there is a way to use 'cpan'/'cpanm' for the
case I am interested in, e.g. either (a) installing only pure-Perl
modules, with dependencies, in my home directory, or (b) installing
binary modules in such a way that they only get used when they are
compatible with the architecture and Perl verion. The goal is to have
a "portable home directory"...

Would adding support for versioned paths to ExtUtils​::MakeMaker and
Module​::Build accomplish (b)?

I am confused by something Dave Mitchell said​:

How are users notified of the fact that system-level modules are being
reinstalled locally [...]

Users will only get this behaviour if they request it.

That suggests that I configured 'cpan' at some time to do this but I
don't remember having done so.

It would be a big help if I could tell 'cpan' to avoid reinstalling
modules which already exist in PERL5LIB. Would this create problems
with users experiencing false bugs that are actually due to module
version mismatches? Relatedly, when CPAN modules depend on each other,
do they depend on a specific version number (which could be checked by
"module managers" like 'cpanm', when deciding to rely on an existing
system-level module installation)?

Thanks,

Frederick

On Tue, Oct 16, 2018 at 04​:15​:50AM -0700, Graham Knop via RT wrote​:

On Mon, Oct 15, 2018 at 1​:39 PM Dave Mitchell <davem@​iabyn.com> wrote​:

On Sat, Oct 13, 2018 at 12​:15​:09PM -0700, (via RT) wrote​:

1. In using 'cpanm' and local​::lib, I thought I was doing the
"standard thing", for example cpanm mentions local​::lib under the
documentation for the "-l, --local-lib" flag. But other people seem to
be installing modules in "version-specific directories", which I don't
even know how to do. It doesn't seem to be the default, since I just
ran 'cpan' in a new user account and after hitting 'enter' at every
prompt and typing 'install List​::BinarySearch', I found that the XS
module was installed here​:

~/perl5/lib/perl5/x86_64-linux-thread-multi/auto/List/BinarySearch/XS/XS.so

I assume this location is not version-specific, since it has no
version number, just the architecture. How does someone (like Dave?)
install a module like List​::BinarySearch without encountering the
above scenario, which he describes as "relatively rare"? (I don't
think my distribution has List​::BinarySearch pre-packaged, but let's
assume that it doesn't)

A perl configured and built using default options *will* use
version-specific paths. Here's a simple test I did just now​:

$ tar xfz ~/perl5/tarballs/perl-5.28.0.tar.gz
$ cd perl-5.28.0/
$ PATH=/bin​:/usr/bin sh Configure -des -Dprefix=/home/davem/tmp/foo/perl && TEST_JOBS=16 HARNESS_OPTIONS=j16 make -j 16 test_harness && make -j 16 install
$ cd ..; $ rm -rf perl-5.28.0
$ cd /home/davem/tmp/foo
$ perl/bin/cpan
cpan[1]> install List​::BinarySearch
Would you like to install List​::BinarySearch​::XS? [y]
$ find . |grep BinarySearch
./perl/lib/site_perl/5.28.0/x86_64-linux/auto/List/BinarySearch
./perl/lib/site_perl/5.28.0/x86_64-linux/auto/List/BinarySearch/XS
./perl/lib/site_perl/5.28.0/x86_64-linux/auto/List/BinarySearch/XS/XS.so
./perl/lib/site_perl/5.28.0/x86_64-linux/auto/List/BinarySearch/XS/.packlist
./perl/lib/site_perl/5.28.0/x86_64-linux/auto/List/BinarySearch/.packlist
./perl/lib/site_perl/5.28.0/x86_64-linux/List/BinarySearch
./perl/lib/site_perl/5.28.0/x86_64-linux/List/BinarySearch/XS.pm
./perl/lib/site_perl/5.28.0/List/BinarySearch.pm
./perl/lib/site_perl/5.28.0/List/BinarySearch
./perl/lib/site_perl/5.28.0/List/BinarySearch/PP.pm
./perl/man/man3/List​::BinarySearch.3
./perl/man/man3/List​::BinarySearch​::XS.3
./perl/man/man3/List​::BinarySearch​::PP.3

Please look carefully at the above, and bear it very keenly in mind for
any further discussion. If that doesn't convince you that perl does in
indeed use version-specific paths *by default*, then you'll have to be
very clear and specific about what your doubts are.

2. I think people were taken aback when I mentioned that I have common
binary modules like Compress​::Raw​::Zlib installed in $HOME. I later
learned this is something that 'cpan' and 'cpanm' do automatically

No, by default cpan etc will try to install under the site_perl directory
of wherever perl was installed, unless you tell it otherwise, e.g. with
options at perl build time, or by using an external tool like local​::lib
to set some environment variables which tells cpan to install somewhere
else.

This is true if you have permissions to install in site_perl. But if
you try to install modules using system perl without running as root,
you probably won't have access to do that.

In that case, both CPAN.pm and cpanm will default to using local​::lib
and installing into ~/perl5, using ExtUtils​::MakeMaker's INSTALL_BASE
option and Module​::Build's --install_base option. Those options don't
use versioned paths.

How are users notified of the fact that system-level modules are being
reinstalled locally, turned into "dual-life modules" as it were?

Users will only get this behaviour if they request it.

The term 'dual-life' is usually used (by us at least) to refer to
something different - where a module is both bundled with perl and
available (possibly in a newer version) on CPAN. It doesn't (very much)
relate to where the module gets installed).

How are other people (like Andy Dougherty?) avoiding 'cpan' install
actions that pull in binary dependencies like Compress​::Raw​::Zlib? I'm
guessing he didn't just "hit enter" at one of the prompts, like I did?

Again, this just doesn't normally occur with a default installation.

Perhaps I'm taking the wrong approach, maybe I should not be using the
'cpan' tool in my use case - namely "unprivileged user with simple
utility scripts that have a few external dependencies". However, I'm
guessing it is a pretty common case, and I realized that the problem
I'm running into with the confusing "binaries mismatched" error
message is something that I could completely avoid if I could tell
'cpan' to refrain from installing what Dan called "dual-life modules",
in other words to stick with installing only modules that are not
already installed system-wide (or elsewhere in PERL5LIB).

No, what you really want to do is, if installing under your home
directory, install version-sensitive files under version-specific paths.
This appears to be a infelicity in the current local​::lib tool. I don't
know a lot about local​::lib, and I'm not a "toolchain guy", so I don't
know whether there's a good reason why local​::lib does things the way it
does or whether it can be altered / extended to include versions in paths.

local​::lib is using the options provided by ExtUtils​::MakeMaker and
Module​::Build. I've worked in the past on using additional options to
force installing into versioned directories, but didn't end up
finishing the work. I had found other options for myself, and nobody
else pushed for fixing the issue until now, so I hadn't gotten back to
it.

Further, when there is an option to install a binary version of a
module, it would be nice to be able to tell 'cpan'/'cpanm' that I am
only interested in the pure-Perl implementation, or at least for it to
install the binary component in such a way that Perl can automatically
fall back on the pure-Perl version of the module, when I find myself
using my scripts on a machine with a different architecture or Perl
version or whatever else would make it impossible to employ the binary
module. In rare cases where I want to depend on a binary module, I
would probably do it by installing the distribution package for that
module, since there is a big overlap between modules which have XS
code and modules which are available in distribution-specific
packages. Basically, a big feature of Perl is backwards compatibility,
and it seems like I should be able to assemble a collection of
modules, using automatic tools like 'cpan', in such a way that they
continue to run correctly on a wide variety of systems.

I think such functionality would have to be done by the distribution
itself on a case-by-case basis.

It seems to me that there are a few bugs or potential areas for
improvement here. Is anyone else concerned about these things, what is
the status, and am I missing something?

My thoughts​:

* The situation is not ideal, but
* fixes are not easy​: this whole area is complex (and not one I
understand well)

--
Technology is dominated by two types of people​: those who understand what
they do not manage, and those who manage what they do not understand.

From @Grinnz

On Thu, 18 Oct 2018 11​:59​:00 -0700, frederik@​ofb.net wrote​:

I guess a summary of this thread is that most Perl developers either
(1) don't use Perl on systems where they don't have root access, or
(2) compile their own Perl and install it somewhere in ~/ in such
cases.

I don't think it's useful to try to categorize what "most" Perl developers do based on a few people's limited perception of the userbase.

It would be a big help if I could tell 'cpan' to avoid reinstalling
modules which already exist in PERL5LIB. Would this create problems
with users experiencing false bugs that are actually due to module
version mismatches? Relatedly, when CPAN modules depend on each other,
do they depend on a specific version number (which could be checked by
"module managers" like 'cpanm', when deciding to rely on an existing
system-level module installation)?

'cpan' and 'cpanm' already skip installing modules which already exist in PERL5LIB, unless the existing version does not satisfy the requirement. CPAN module dependencies often include a version requirement, and the 'cpanm' client can take a version requirement directly​: Some​::Module@​1.23

-Dan

From frederik@ofb.net

On Thu, Oct 18, 2018 at 12​:24​:18PM -0700, Dan Book via RT wrote​:

On Thu, 18 Oct 2018 11​:59​:00 -0700, frederik@​ofb.net wrote​:

I guess a summary of this thread is that most Perl developers either
(1) don't use Perl on systems where they don't have root access, or
(2) compile their own Perl and install it somewhere in ~/ in such
cases.

I don't think it's useful to try to categorize what "most" Perl developers do based on a few people's limited perception of the userbase.

Oh sorry I meant ... "developers *of* Perl" not "developers *with*
Perl". One of the questions I have been trying to answer is why other
contributors to this thread don't run into the same problems that I'm
running into, why Dave considers a situation which I had thought would
be a default one, to be "relatively rare", why Andy was surprised that
I have Compress​::Raw​::Zlib installed locally, etc.

'cpan' and 'cpanm' already skip installing modules which already exist in PERL5LIB, unless the existing version does not satisfy the requirement. CPAN module dependencies often include a version requirement, and the 'cpanm' client can take a version requirement directly​: Some​::Module@​1.23

Thank you, that's helpful to know. In my email of "Tue, 21 Aug 2018
16​:43​:58 -0700" I mentioned having noticed Compress​::Raw​::Zlib
reappear in ~/.local after uninstalling it. Presumably I ran 'cpan -r'
and something depended on the latest version?
/usr/lib/perl5/5.28/core_perl/Compress/Raw/Zlib.pm has 2.076, vs 2.081
for the latest version?

Also I'm confused by the syntax, I would have thought the second
command should also report the module being up to date​:

$ cpanm Compress​::Raw​::Zlib@​2.076
Compress​::Raw​::Zlib is up to date. (2.076)
$ cpanm 'Compress​::Raw​::Zlib~>=2.076'
--> Working on Compress​::Raw​::Zlib
Fetching http​://www.cpan.org/authors/id/P/PM/PMQS/Compress-Raw-Zlib-2.081.tar.g

Thanks,

Frederick

From @Grinnz

On Thu, 18 Oct 2018 13​:00​:06 -0700, frederik@​ofb.net wrote​:

Also I'm confused by the syntax, I would have thought the second
command should also report the module being up to date​:

$ cpanm Compress​::Raw​::Zlib@​2.076
Compress​::Raw​::Zlib is up to date. (2.076)
$ cpanm 'Compress​::Raw​::Zlib~>=2.076'
--> Working on Compress​::Raw​::Zlib
Fetching http​://www.cpan.org/authors/id/P/PM/PMQS/Compress-Raw-Zlib-
2.081.tar.g

2.076 is not the latest version. @​2.076 arranges to have exactly that version installed, whereas ~2.076 arranges for that version or higher, equivalent to ~'>= 2.076', and it seems cpanm will take this to mean that it should upgrade the module.

-Dan

From @Grinnz

On Thu, 18 Oct 2018 13​:18​:40 -0700, grinnz@​gmail.com wrote​:

On Thu, 18 Oct 2018 13​:00​:06 -0700, frederik@​ofb.net wrote​:

Also I'm confused by the syntax, I would have thought the second
command should also report the module being up to date​:

$ cpanm Compress​::Raw​::Zlib@​2.076
Compress​::Raw​::Zlib is up to date. (2.076)
$ cpanm 'Compress​::Raw​::Zlib~>=2.076'
--> Working on Compress​::Raw​::Zlib
Fetching http​://www.cpan.org/authors/id/P/PM/PMQS/Compress-Raw-Zlib-
2.081.tar.g

2.076 is not the latest version. @​2.076 arranges to have exactly that
version installed, whereas ~2.076 arranges for that version or higher,
equivalent to ~'>= 2.076', and it seems cpanm will take this to mean
that it should upgrade the module.

You can pass --skip-satisfied to cause it to skip installing the module when it's not at the latest version, but satisfies the specified version range.

-Dan

From @haarg

On Thu, 18 Oct 2018 13​:18​:40 -0700, grinnz@​gmail.com wrote​:

On Thu, 18 Oct 2018 13​:00​:06 -0700, frederik@​ofb.net wrote​:

Also I'm confused by the syntax, I would have thought the second
command should also report the module being up to date​:

$ cpanm Compress​::Raw​::Zlib@​2.076
Compress​::Raw​::Zlib is up to date. (2.076)
$ cpanm 'Compress​::Raw​::Zlib~>=2.076'
--> Working on Compress​::Raw​::Zlib
Fetching http​://www.cpan.org/authors/id/P/PM/PMQS/Compress-Raw-Zlib-
2.081.tar.g

2.076 is not the latest version. @​2.076 arranges to have exactly that
version installed, whereas ~2.076 arranges for that version or higher,
equivalent to ~'>= 2.076', and it seems cpanm will take this to mean
that it should upgrade the module.

-Dan

There is in important difference in behavior between modules mentioned directly on the command line vs prerequisites. Prerequisites will only be upgraded if necessary. Modules specified on the command line will always be upgraded if there is a newer version available that satisfies the version requirements given, unless --skip-satisfied is used.