Bug 1936241

The move from /usr/local/share/perl to /usr/local/share/perl/$VERSION was done in Fedora 31 (with Perl 5.30). It was documented in Fedora 31 Release Notes <https://docs.fedoraproject.org/en-US/fedora/f31/release-notes/developers/Development_Perl/>.

The reason for the move was that every second Fedora delivers a new, binary incompatible, perl and people who blindly installs modules from CPAN were reporting that "perl stopped working after Fedora upgrade". The problem was that the new interpreter attempted to load and execute their old modules built for the previous perl. The recommended solution for them was to reinstall their CPAN modules. But that proved to be difficult because the reinstallation itself could have been affected by the very same incompatible modules. Therefore we decided to start versioning the Perl site path. That way everybody needs to reinstall their CPAN modules if he wants use them with the new perl. It's less error prone than keeping the paths polluted with the old CPAN modules and getting unexpected crashes when loading the old modules by an accident. At the end it's what other software distributions (e.g. Debian or Gentoo) do. It stems from the fact that every new perl as provided by Perl5 Porters is binary incompatible.

Thank you for a detailed explanation on an old bug.

This is wrong.

That reasoning is sound for sitearch, which contains architecture-dependent (binary) module files. It makes plenty of sense to look for such modules in an ABI-version-dependent directory; Perl has done that since 5.005 or so.

It is completely inapplicable to sitelib, which contains architecture-independent modules. Such modules are non-binary and so cannot be ABI-version-dependent. They do not need to be in a versioned directory tree.

This may come as a surprise, but CPAN is not everything. Lots of us have private, site-specific modules. Most of those are pure-perl. Most of them are relatively simple -- a single file, or a small tree of files. And most of them are installed by dropping files in the right place, via whatever mechanism we are using to manage hundreds or thousands of machines. They are not built on each machine, or even "built" at all -- Perl's module build system is great for modules that actually have something that need to be compiled, but way overkill for something that just needs a few files to be dropped into perl's sitelib directory.

It is a huge problem for Perl to suddenly stop looking in that site-specific, version-agnostic location across an upgrade. Even if that is a major-version upgrade like RHEL8->RHEL9 (which is the first time enterprise customers saw this, and not all tha long ago on the timescale of people who manage thousands of machines supporting hundreds of applications).

In fact, it's a huge problem to have to guess what is the correct location, on a per-machine basis, depending on what version of perl might be there.


This is a regression. /usr/local/share/perl5 worked in RHEL7 and RHEL8; it does not work in RHEL9. Apparently the same was true with Fedora 30->31.
Perhaps Red Hat is not interested in fixing this bug. But it is certainly a bug.

You want an optimization for architecture independent modules. That understandable.

However, that optimization would break reinstallation from CPAN that mixes architecture dependent and independent modules: Module A is in sitelib and requires module B in sitearch. The user is unaware of B, he explicitly installed A. After upgrading Fedora, A becomes broken because B is not available. The user attempts to reinstall A, but that "succeeds" with an explanation that A is already installed. Hence the user cannot repair it.

I was aware of the inconvenience the current approach brings, but weighting in the CPAN problem and the fact other Linux distribution do it, I concluded that this it the best compromise.
Current Fedora perl maintainers might have a different opinion.

If you want to argument with RHEL, please report your issue to Red Hat support <https://access.redhat.com/support/>.