dual life modules, @INC, and the tyranny of shipping upgrades

I was trying to write a paragraph on the new @INC order for perl5110delta.pod
(because I don't spot anyone else doing it)

So, the two disadvantages of the old @INC order are that

1: All upgrades to dual life modules have to go in "perl" rather than "site",
   which confuses package managers. (Which in turn sometimes exact revenge)

2: Modules shipped with a new stable release occlude all modules supplied or
   upgraded under previous releases ("site" or "perl").

   Which means that a maintenance release feels compelled to ship all the
   latest versions of dual life modules, else anyone installing it might
   downgrade the available version of a dual life module, which could
   re-introduce bugs.

But then I realised

i:  the new order doesn't solve point 2
ii: so I tried to work out how to do it, and I think I realised that you can't
    solve it with @INC order alone.


Consider a chronological shipping order

a: Perl 5.14.0, incorporating Foo 1.00
b: Perl 5.14.1, incorporating Foo 1.00
c: Foo 1.01
d: Foo 1.02
e: Perl 5.14.2, incorporating Foo 1.02. Moreover, Foo 1.01 and earlier
   don't work with 5.14.2


Currently we have:

5.14.0 "site"
5.14.0 "perl" Foo 1.00

some point after "c", the user upgrades Foo:

5.14.0 "site" Foo 1.01
5.14.0 "perl" Foo 1.00

then the user upgrades to 5.14.1:

5.14.1 "site"
5.14.1 "perl" Foo 1.00
5.14.0 "site" Foo 1.01

Oops. An enforced downgrade.

We could solve that by having all "site" directories come first:

5.14.1 "site"
5.14.0 "site" Foo 1.01
5.14.1 "perl" Foo 1.00


but then consider what happens after "e", when the user upgrades to 5.14.2:

5.14.2 "site"
5.14.1 "site" 
5.14.0 "site" Foo 1.01
5.14.2 "perl" Foo 1.02

Kaboom! A non-working install. Whereas the current order ensures that core
can force the necessary upgrade to keep working:

5.14.2 "site"
5.14.2 "perl" Foo 1.02
5.14.1 "site" 
5.14.0 "site" Foo 1.01



So I was wondering how to do this with a more complex @INC structure.
And I'm not sure if it's possible. Certainly, it's complex.


The *simplest* solution seems to be for Configure to have the optional
capability, if it detects an older perl version to add to @INC, to probe
that perl to see what dual life modules it has installed, and then to opt to
de-Configure those modules for this version of perl.

This will work.

However, it raises 2 questions

1: How to run the regression tests, given that some modules won't be built
   into the build tree's lib/ because they're not going to be installed.
   Or do we build them anyway, but not install them?
   That way the tests run, but not with the exact versions of modules that
   will be in place after the install.
   Or do we include "site" in @INC?
   Which can be a bad idea, because right now some core tests fail or get 
   confused if they pick up modules from the install path. And TestInit.pm
   currently forces @INC to be solely within the build tree to avoid this
   contamination and confusion.

2: Whether it's good that we now have a way to install 5.14.2, such that it
   depends on 5.14.1 or 5.14.0's "site" tree still being there to provide it
   with key parts of its functionality.


What do people think?

If there's a clear way to solve this, it makes ongoing maint releases much
much easier, both for the maintainers, and anyone choosing to install them
more than 2 days after they are released.


Nicholas Clark

• dual life modules, @INC, and the tyranny of shipping upgrades by Nicholas Clark
• Re: dual life modules, @INC, and the tyranny of shipping upgrades by Andy Dougherty
• Re: dual life modules, @INC, and the tyranny of shipping upgrades by Gerard Goossen
• Re: dual life modules, @INC, and the tyranny of shipping upgrades by Nicholas Clark
• Re: dual life modules, @INC, and the tyranny of shipping upgrades by Aristotle Pagaltzis
• Re: dual life modules, @INC, and the tyranny of shipping upgrades by Paul Johnson
• not my original question (was Re: dual life modules, @INC, and the tyranny of shipping upgrades) by Nicholas Clark