Noben has asked for the wisdom of the Perl Monks concerning the following question:

Hello! I haven't been able to find an answer yet on this, I have my perl set up w/ local::lib so they are all in the ownership of my user, not root. Though i did have to install some modules outside of cpan and i used sudo make install. I didn't think about it at the time and now looking in perl5/lib/perl5 i see a few modules w/ root::root ownership. Does this affect their use if not a superuser running scripts? should there be any root ownership of modules in local::lib? thanks! nob

Replies are listed 'Best First'.
Re: Local::lib and root an issue?
by Nemo Clericus (Beadle) on Jan 14, 2015 at 21:40 UTC
    Well, this would depend on whether the permissions of the modules allow a user or group other than root to read the contents therein. Also, the only reason there should be root owned modules in local::lib would be if it was the local::lib of root. It doesn't make much sense to use local::lib if the user doesn't own the modules. You of course can make it work however - but wouldn't that just be awfully ugly?
      so maybe sudo chown -R username:username perl5 ?
        Sure, that should be just fine.
Re: Local::lib and root an issue?
by locked_user sundialsvc4 (Abbot) on Jan 15, 2015 at 02:06 UTC

    You should just generally treat this situation as a variation of “installing Perl libraries as a non-root user,” which is already richly provided-for in Super Search.   You want to set up PERL5LIB and CPAN configuration such that there is an entirely-separate directory into which everything is installed.   (This may also necessitate creating a local library search-path for .so [or Windows .dll] files, as well.)

    In general, you don’t ever want to necessitate “sudo anything.”   Pretend that you are not able to do that.   Many (say ...) Linux distros rely heavily upon Perl to run their software configuration-management systems, and I am therefore very reluctant to do anything that might disturb that.   I want my local installs to sit entirely on-top-of anything at the system level.   And that includes any (XS ...) object-module code.