From @Leont

inc_version_list is a feature that allows one to re-use the pure-perl
modules in a freshly compiles perl, provided they use the same prefix (e.g.
/usr/lib/perl/). Configure automatically detects previous versions and
unless inc_version_list=none is given, it will add them to the list

This mechanism only reuses pure-perl libs by default. This means that if
any pure-perl module A has an XS dependency B, it will not be able to load
B. Worse yet, because cpan clients will (correctly) detect A is already
installed, they will not try to install B (unless it's depended on directly
somewhere else).

Quite frankly, it's very hard to explain to end-users "your system is
broken for these purposes, you have to change your entire setup, or expect
to fixup by hand with some regularity". And frankly, that's the best I have
to offer them right now.

This behavior can be useful in simple cases, but it's outright wrong in a
lot of more complicated cases. Wrong and probably unfixable. Therefor, I
propose not to do this by default anymore. The behavior should still be
available for those who want it, but in the majority of cases it should not
be used.

Leon

From @cpansprout

On Sun Oct 06 13​:12​:42 2013, LeonT wrote​:

inc_version_list is a feature that allows one to re-use the pure-perl
modules in a freshly compiles perl, provided they use the same prefix
(e.g.
/usr/lib/perl/). Configure automatically detects previous versions and
unless inc_version_list=none is given, it will add them to the list

This mechanism only reuses pure-perl libs by default. This means that if
any pure-perl module A has an XS dependency B, it will not be able to load
B. Worse yet, because cpan clients will (correctly) detect A is already
installed, they will not try to install B (unless it's depended on
directly
somewhere else).

Quite frankly, it's very hard to explain to end-users "your system is
broken for these purposes, you have to change your entire setup, or expect
to fixup by hand with some regularity". And frankly, that's the best I
have
to offer them right now.

This behavior can be useful in simple cases, but it's outright wrong in a
lot of more complicated cases. Wrong and probably unfixable. Therefor, I
propose not to do this by default anymore. The behavior should still be
available for those who want it, but in the majority of cases it
should not
be used.

+1

--

Father Chrysostomos

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

From @ikegami

On Mon, Oct 7, 2013 at 12​:39 PM, Andy Dougherty <doughera@​lafayette.edu>wrote​:

Could you give a specific example set of modules A and B and a
set of cpan commands that will trigger the problem?

Say you have a module or app that uses Net​::Amazon​::S3. You've been using
5.16.3, but you want to switch to 5.18.1. After you install 5.18.1, you do

  cpan Net​::Amazon​::S3

cpan will detect that Net​::Amazon​::S3 is installed and won't attempt to
install it again if inc_version_list includes 5.16.3.

All's good? No. If you try to actually use Net​::Amazon​::S3, it will fail
when it attempts to use XML​::LibXML.

From @doughera88

On Tue, Oct 08, 2013 at 04​:28​:30PM -0400, Eric Brine wrote​:

On Mon, Oct 7, 2013 at 12​:39 PM, Andy Dougherty <doughera@​lafayette.edu>wrote​:

Could you give a specific example set of modules A and B and a
set of cpan commands that will trigger the problem?

Say you have a module or app that uses Net​::Amazon​::S3. You've been using
5.16.3, but you want to switch to 5.18.1. After you install 5.18.1, you do

cpan Net​::Amazon​::S3

cpan will detect that Net​::Amazon​::S3 is installed and won't attempt to
install it again if inc_version_list includes 5.16.3.

All's good? No. If you try to actually use Net​::Amazon​::S3, it will fail
when it attempts to use XML​::LibXML.

Thank you for the good example. (Wow, that is one deep dependency chain.)

I do find it slightly odd that this is widely viewed as a problem with
inc_version_list, and not a bug in cpan for failing to correctly determine
that the dependencies aren't installed. Since I know that installing
a new major version of perl requires recompiling all XS extensions,
it would simply never have occured to try upgrading without doing so as
part of the upgrade. But I don't pretend my experience is particularly
relevant here.

In any case, I agree the workaround for the end user is the same.
The following (untested) patch to Configure ought to do the trick,
but it shouldn't be applied without also fixing up the documentation in
INSTALL and Porting/Glossary (which is autogenerated from metaconfig).
This patch also doesn't offer the user an *easy* way to revert to the
previous behavior, though explicitly specifying inc_version_list should
still work. (I toyed with the idea of adding a new variable, something
like $pure_perl_back_version, that could be set from the Configure command
line, but would default to $api_versionstring, but didn't have time to
think it all the way through, including documentation and testing.)

--- Configure	2013-05-10 10:13:56.000000000 -0400
+++ Configure.new	2013-10-11 08:29:30.000000000 -0400
@@ -6518,16 +6518,13 @@
     ;@candidates = ();
 }
 
-($pversion, $aversion, $vsn5005) = map {
-    pack "sss", split m/[._]/, "$_.0.0" } $version, $api_versionstring, "5.005";
+($pversion, $aversion) = map {
+    pack "sss", split m/[._]/, "$_.0.0" } $version, $api_versionstring;
 foreach $d (@candidates) {
     if ($d->[1] lt $pversion) {
 	if ($d->[1] ge $aversion) {
 	    unshift(@inc_version_list, grep { -d } $d->[0]."/$archname", $d->[0]);
 	}
-	elsif ($d->[1] ge $vsn5005) {
-	    unshift(@inc_version_list, grep { -d } $d->[0]);
-	}
     }
     else {
 	# Skip newer version.  I.e. don't look in


-- 

  Andy Dougherty doughera@​lafayette.edu

From @rjbs

* Andy Dougherty <doughera@​lafayette.edu> [2013-10-11T08​:45​:07]

I do find it slightly odd that this is widely viewed as a problem with
inc_version_list, and not a bug in cpan for failing to correctly determine
that the dependencies aren't installed.

CPAN trusts that if X is installed, so are its prereqs. Were it to do
otherwise, it would have to re-download and re-configure every prerequisite
recursively to know their prerequisites, or it would need to store the MYMETA
(or equivalent) of each dist, etc.

--
rjbs

From @Leont

On Fri, Oct 11, 2013 at 2​:45 PM, Andy Dougherty <doughera@​lafayette.edu>wrote​:

I do find it slightly odd that this is widely viewed as a problem with
inc_version_list, and not a bug in cpan for failing to correctly determine
that the dependencies aren't installed.

CPAN *can't* fix this by design. CPAN can't know second order dependencies,
that information is not stored post-installation. There has been talk about
storing that extra information in the future, but we're not there yet. It
only checks for first order dependencies.

Since I know that installing
a new major version of perl requires recompiling all XS extensions,
it would simply never have occured to try upgrading without doing so as
part of the upgrade. But I don't pretend my experience is particularly
relevant here.

That requires you to know all your XS extensions, which generally speaking
people don't know. Nor is it obvious how to figure out which XS extensions
you have installed («find $(perl -MConfig -E 'say
$Config{installsitearch}') -name '*.so'» comes pretty close)

Leon

From @andk

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

Since I know that installing
a new major version of perl requires recompiling all XS extensions\,
it would simply never have occured to try upgrading without doing so as
part of the upgrade\.  But I don't pretend my experience is particularly
relevant here\.

That requires you to know all your XS extensions, which generally speaking
people don't know. Nor is it obvious how to figure out which XS extensions you
have installed («find $(perl -MConfig -E 'say $Config{installsitearch}') -name
'*.so'» comes pretty close)

And there is a recompile command in the cpan shell for this purpose.

--
andreas