[Bug 1936241] New: Compiled @INC in 5.32 No longer Includes Suitable Path For Custom System-Wide Modules
https://bugzilla.redhat.com/show_bug.cgi?id=1936241
Bug ID: 1936241 Summary: Compiled @INC in 5.32 No longer Includes Suitable Path For Custom System-Wide Modules Product: Fedora Version: 33 Hardware: All OS: Linux Status: NEW Component: perl Severity: medium Assignee: jplesnik@redhat.com Reporter: claywj@gmail.com QA Contact: extras-qa@fedoraproject.org CC: caillon+fedoraproject@gmail.com, iarnell@gmail.com, jplesnik@redhat.com, kasal@ucw.cz, mmaslano@redhat.com, perl-devel@lists.fedoraproject.org, ppisar@redhat.com, psabata@redhat.com, rhughes@redhat.com, sandmann@redhat.com, spotrh@gmail.com Target Milestone: --- Classification: Fedora
Description of problem:
Removing /usr/local/share/perl5 for the version specific dir with 5.32 from the compiled @INC makes it difficult to maintain custom system wide modules apart from the standard rpm/CPAN locations when upgrading.
As this is done during build, is it possible to get it added back in the next version?
Version-Release number of selected component (if applicable):
5.32
How reproducible:
perl -e 'print "@INC\n"'
Steps to Reproduce:
1. Using CVS/SCM software to update a custom module, it goes to the expected old location no longer part of @INC and the changes are not seen.
Actual results:
See above
Expected results:
The path would remain and the changes seen
Additional info:
Yes, CVS/SCM can be changed but in this case the update came across on "Thu 25 Feb 2021 04:46:53 PM CST" during updates. The installer did relocate the existing custom modules to ./5.32 but the change was not noticed until an update to one of the custom modules took place
https://bugzilla.redhat.com/show_bug.cgi?id=1936241
Petr Pisar ppisar@redhat.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |CLOSED Resolution|--- |NOTABUG Doc Type|--- |If docs needed, set a value Last Closed| |2021-03-08 14:20:02
--- Comment #1 from Petr Pisar ppisar@redhat.com --- 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.
https://bugzilla.redhat.com/show_bug.cgi?id=1936241
Jeffrey Hutzelman jhutz@cmu.edu changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jhutz@cmu.edu
--- Comment #3 from Jeffrey Hutzelman jhutz@cmu.edu --- 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.
https://bugzilla.redhat.com/show_bug.cgi?id=1936241
--- Comment #4 from Petr Pisar ppisar@redhat.com --- 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/.
perl-devel@lists.fedoraproject.org
-
bugzilla＠redhat.com