in reply to Fedora 29 upgrade

If you do not have perlbrew installed then this is a good time to install it. It is really simple to install and even simpler to tell it to fetch a perl you want, compile it (itself, not you) and switch to using it.

In this way you leave system perl alone. There are a lot of system processes which depend on perl and possibly specific perl version. If you upgrade a package because a user needs it, then that system process can break. If you upgrade as root you override already existing versions. If you upgrade/install as user in your local dirs then the probability of damage is much less but you then depending on @INC and the paths order, you get this "unexplained" behaviour.

The benefits of perlbrew (or any other similar "alternatives" system) are obvious and the procedure is painless, as it is the learning curve (none basically).

If you must debug this issue, then try to get more information:

perl -MXML::Parser::Expat -e 'print qq/success/'

perl -MXML::Twig -e 'print qq/success/'

perl -e 'print qq/@INC/'

which perl

which cpanm

which cpan

and finally find any Expat installations (may take some time):

find / -type f -name 'Expat.so'

Replies are listed 'Best First'.
Re^2: Fedora 29 upgrade
by Fletch (Bishop) on Aug 08, 2019 at 14:22 UTC

    Seconding this advice. The effort is more worth it when you're not scrambling because your application doesn't break when the OS' perl gets changed underneath it because the corporate IT people pushed a newer package to your systems without consulting you.

    Not that I speak from experience here or anything . . . *cough*

    The cake is a lie.
    The cake is a lie.
    The cake is a lie.

[reply]

      I am at the moment starting some fresh fedora install and I am doing just that with the additional twist that I want perlbrew-managed perls to be installed by superuser(=root) so that all users can use them without each installing their own. Additionally I want root to install a good deal of common modules (e.g. LWP) for all users. After that, if users need to install obscure modules in their own private/home dirs, it is up to them. Or they ask superuser to install it for everybody in public dir.

      I have found that this setup entails some danger.

      Because I do not want root to have in their login/startup script all those perlbrew-related variables. Perhaps that's a purist view but I opted for creating a script for root to use whenever is going to need to do perlbrew-housekeeping and not having that same commands in root's .bashrc. Something like:

      #!/bin/sh
# this is bin/use-perlbrew.sh (not part of ~/.bashrc)
export PERLBREW_ROOT=/opt/perlbrew
export PERLBREW_HOME=${HOME}/.perlbrew
source ${PERLBREW_ROOT}/etc/bashrc
CMD="perlbrew use perl-5.30.0"
echo "$0 : executing: ${CMD}"
eval ${CMD}
if [ $? -ne 0 ]; then echo "$0 : command has failed ${CMD}"; exit 1; f
+i

      [download]

      So, on login, root uses system perl and does not know about any perlbrew stuff. If root has to install perlbrew-wise modules then runs above script first (EDIT: via source ~/bin/use-perlbrew.sh). I find this cleaner than staffing root's .bashrc with tom, dick and harry.

      I am aware that perlbrew can manage the system perl as well with just a symlink - no need of re-installing it (thanks to https://stackoverflow.com/questions/25188575/switching-to-the-system-perl-using-perlbrew). So one can suggest adding the perlbrew variables+source in root's .bashrc and immediately after that add perlbrew use system.

      I suspect my dislike of that is cargo-culting. Anyone knows better? (I think I will SOPW this)

      45 min EDIT: gaining root access via plain su inherits all env vars from current shell. Which includes all the perlbrew variables the calling user had. su --login stops that and is the proper way to gain root access if not doing it from the login screen.

[reply]
[d/l]
[select]

In Section Seekers of Perl Wisdom