Description of problem: Upon installing the perl-homedir RPM (which seems to be default in some RHEL/CentOS 7 configurations) a profile.d entry is added which enables a local::lib for all users, including root. The root user should not have a local::lib, as this means 'sudo cpan' or 'sudo cpanm' (though inadvisable) will install into a location unusable by any other user, rather than the global sitelib as expected. Version-Release number of selected component (if applicable): perl-homedir-2.000024-4.fc29.noarch How reproducible: Always Steps to Reproduce: 1. install perl-homedir 2. switch to root user 3. check perl -V Actual results: ~/perl5 is created for root user and local::lib environment variables and directories are visible in perl -V output. Expected results: No local::lib is created or activated for the root user by default. Additional info:
While 'sudo cpan' is inadvisable since it can confuse RPM-managed perl libraries, and is harder to fix in distro upgrade to an incompatible perl than a local::lib, it is also the simplest way to install a library for multi-user use that is not available as an RPM already. Thus I would rather be able to recommend use of this module (so local::lib is used by default) than to recommend removing it so 'sudo cpan' works normally.
You can exclude any user from perl-home-dir effect by creating $HOME/.perl-homedir shell script that changes PERL_HOMEDIR=1 environment variable to a different value or that unsets it. I believe you can do it for root user too. You can also configure CPAN to install to site paths instead to local::lib if you want. I don't think diverging the behavior for root user makes sense. It would make the system more complicated.
(In reply to Petr Pisar from comment #2) > > I don't think diverging the behavior for root user makes sense. It would > make the system more complicated. Agreed. +1 for WONTFIX.
This message is a reminder that Fedora 29 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora 29 on 2019-11-26. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '29'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 29 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
This issue is not specific to Fedora 29 and is still present in 30 and 31.
And I said this is an intended behavior.