Making Perl site paths ABI-specific

[Petr Pisar]

It was a long time ago I wrote to this list. I'm thinking about changing site
paths.

Now, perl configures site paths to:

    /usr/local/lib64/perl5
    /usr/local/share/perl5

so that anyone installing distributions from CPAN in a system-wide manner will
install his modules there. These two paths are listed before core and vendor
path used by Fedora packages in order to allow users to override Perl modules
coming with Fedora.

This layout has the nice feature that user's code is available across Fedora
upgrades. However, this feature is also bad because perl tends to change ABI
and as a result XS modules stop working and becuse the site location
precedence they can hinder even Fedora's Perl code. Then inexperienced users
report bugs for perl that Perl stopped working after upgrade Fedora.

My proposal is make the two paths changing with every new incompatible Perl
release (that happens every year with a new minor Perl version). Example:

    /usr/local/lib64/perl5/5.30
    /usr/local/share/perl5/5.30

As a result when users upgrade to Perl 5.30, their locally installed modules
become unavailable and thus they won't be able to affect the new system. Also
the user immediatelly recongnizes that his locally installed code
"disappeared" instead of receiving some cryptic error message from XSLoader
few days later when some optional XS module gets loaded.

These version specific paths are nothing new. Actually a vanilla Perl
installation uses more elaborate path differentiating threaded and
non-threaded builds in addition. See Debian or Gentoo.

It's important to note that INSTALLSITEBIN would remain /usr/local/bin
because nobody's going to add /usr/local/bin/5.30 in PATH manually. (We could
deliver a /etc/profile.d file within perl-libs, but I think it would made
things more fragile.)

One also could be tempted to keep the architecture independent
/usr/local/share/perl5 as it is. But that could keep modules without
architecture-specific dependencies available after an upgrade. So I believe we
should move both paths.

So if we conclude that this change is good and should be implemented, the only
uncertainity is the issue of aestetic: How exactly should the paths be named?
I can see these posibilities:


    /usr/local/share/perl5/5.30
    /usr/local/share/perl5/30
    /usr/local/share/perl5.30

The first two keep all Perl files under one directory, while the third one
proliferates directories right under /usr/local/share. It also is backward
compatible for people who back up or NFS-mount the paths. The last two makes
the path a little bit shorter. While the first and last resembles a soname we
already give to libperl.so (/usr/lib64/libperl.so.5.30). The first two have
also a very tiny posibility of a clash with Perl modules namespaced into
"5.30::" or "30::" that could survive from current days (installed
into
/usr/local/share/perl5). I like the first option.

Any opinions? Should we go with this change? Wich format do you like most?

-- Petr