[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(a)redhat.com
          Reporter: claywj(a)gmail.com
        QA Contact: extras-qa(a)fedoraproject.org
                CC: caillon+fedoraproject(a)gmail.com, iarnell(a)gmail.com,
                    jplesnik(a)redhat.com, kasal(a)ucw.cz,
                    mmaslano(a)redhat.com,
                    perl-devel(a)lists.fedoraproject.org, ppisar(a)redhat.com,
                    psabata(a)redhat.com, rhughes(a)redhat.com,
                    sandmann(a)redhat.com, spotrh(a)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


-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug 1936241] Compiled @INC in 5.32 No longer Includes Suitable Path For Custom System-Wide Modules

https://bugzilla.redhat.com/show_bug.cgi?id=1936241

Petr Pisar <ppisar(a)redhat.com&gt; 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(a)redhat.com&gt; ---
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/...;.

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.


-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug 1936241] Compiled @INC in 5.32 No longer Includes Suitable Path For Custom System-Wide Modules

https://bugzilla.redhat.com/show_bug.cgi?id=1936241

Jeffrey Hutzelman <jhutz(a)cmu.edu&gt; changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jhutz(a)cmu.edu



--- Comment #3 from Jeffrey Hutzelman <jhutz(a)cmu.edu&gt; ---
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 are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=1936241

Report this comment as SPAM:
https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla&format=rep...

[Bug 1936241] Compiled @INC in 5.32 No longer Includes Suitable Path For Custom System-Wide Modules

https://bugzilla.redhat.com/show_bug.cgi?id=1936241



--- Comment #4 from Petr Pisar <ppisar(a)redhat.com&gt; ---
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/>;.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=1936241

Report this comment as SPAM:
https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla&format=rep...