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

Sry for this weak title, but I don't have any idea for a better one.
I'm working on a rockylinux. There is perl preinstalled /usr/bin/perl. I installed mod_perl via yum and used apache/perl-status to check on it. Based on perl-status: I can see version + modules:

Embedded Perl version v5.26.3 for Apache/2.4.37 (rocky) mod_perl/2.0.1
+2 Perl/v5.26.3 process 12268,
@INC =
/MYSTUFF/dev/site/modules/collection
/MYSTUFF/dev/site/modules/core
/usr/local/lib64/perl5
/usr/local/share/perl5
/usr/lib64/perl5/vendor_perl
/usr/share/perl5/vendor_perl
/usr/lib64/perl5
/usr/share/perl5
/etc/httpd
/MYSTUFF/dev/site/modules/fallback

[download]

1) How do you update mod_perl? Let's just pretend I wanted to update mod_perl to use a newer perl version. Do I have to compile it by myself while linking to my local installed perl?
2) Does this mean mod_perl will by default use my local perl modules (@INC)?
3) Why can I install mod_perl from my package manager without him knowing which perl I got? Does it just look for the system default one and use this one? Then 1) would be a false idea?

Ending this, one more question regarding cpan. Does it matter under which user I install perl-modules using cpan? So far I use root because I get some permission issues e.g. while installing DBI.

Replies are listed 'Best First'.
Re: Questions about mod_perl modules and dependencies.
by hippo (Archbishop) on Mar 30, 2022 at 10:10 UTC

    1) Yes, you have to compile it yourself using your newer perl.

    2) mod_perl will search the @INC that it reports for installed modules. If your question meant something else, please elaborate.

    3) You can't - the mod_perl package depends on the perl package.

    If you want to use a newer perl for some reason then you would be better off compiling and installing it and its modules (including mod_perl) yourself and ignoring the system perl entirely. There have been many, many discussions about this here in the past.

    As an aside, Rocky 9 will be out soon since RHEL 9 is in late beta so if you just want something newer than 5.26.3 then maybe wait a few months and you could use that as your distro and have it all packaged for you.

    Does it matter under which user I install perl-modules using cpan? So far I use root because I get some permission issues e.g. while installing DBI.

    It matters. You must install as root if you want to install them in a directory which is only writable by root of course. But maybe you don't need to install them there? Either way, only install as root - don't compile or test as root for security reasons. cpanm has the handy --sudo option for operating in this way.

    🦛

[reply]
[d/l]

      Sorry for answering late.
      2) @INC is an array with paths where perl is looking for modules. As far as I know @INC is set to the system default perl (let's call it "system-perl" for now). So if I would install a second perl (let's call it "rh-perl") on my linux it would install perl under /opt/rh-perl/5.xx.x, how does this affect @INC? Would @INC still show the system-perl paths instead of my rh-perl paths? Would it show both paths?
      I'd assume each perl version got a different @INC array. system-perl got different path's in it then rh-perl does. So if I would compile mod_perl with rh-perl @INC for mod_perl then would be the new rh-perl paths, right?

      Even Rocky 8 is totally fine for me. It's just for an proof of concept where I need perl. The original vm used to be CentOS7 which had perl 5.16.3 which doesn't work for this task.

[reply]

        Each perl binary will have its own @INC and IIRC the mod_perl that you build using that perl binary inherits the @INC from it. However, the @INC which any particular mod_perl installation starts with can always be modified in the configuration afterwards so it is not the be all and end all to get it right first time.

        🦛

[reply]

Back to Seekers of Perl Wisdom