|
Wiggins has asked for the wisdom of the Perl Monks concerning the following question:
I think I have a better chance to have this question answered here than in the CentOS community.
Testing a system I wrote in Perl on a freshly installed CentOS 7 system, it threw a 'not found' error for 'version.pm'. WTFO?.
I know! That is not Perl's fault. But, can someone from the CentOS community, tell me why a module that critical, is missing? Then, cpan is also missing.
I try to write using only core modules (it makes for more universal installs), but on CentOS 7, I have to do a 'yum install' before I can run the installer written in Perl.
It is always better to have seen your target for yourself, rather than depend upon someone else's description.
|
Re: Why not include version.pm
by hippo (Bishop) on Mar 26, 2016 at 14:57 UTC
|
can someone from the CentOS community, tell me why a module that critical, is missing?
I have no official standing within the CentOS community but am a user of CentOS and RHEL. The version module isn't "missing" - it's in the repository. You simply have to install it to use it just like you would any other piece of software.
RedHat doesn't bundle all the perl core into a single RPM because it would mean changing the entire bundle every time one of the constituent modules is upgraded and that would not be very efficient. Since one person's "critical" is another person's "waste of valuable space" the choice of which bits of core to install is up to the user. If you want all of core installed right from the off just install the cleverly-named perl-core RPM which is a meta package and pulls in all the core modules as dependencies.
| [reply] |
Re: Why not include version.pm
by Your Mother (Archbishop) on Mar 25, 2016 at 23:23 UTC
|
In my view Red Hat and consequently CentOS has been hostile to Perl for more than a decade; they had a disastrous build 10ish years ago that *crippled* any OO Perl code and it remained unrepaired for two years despite ardent requests for a simple build fix. I don't know if it's intentional, for example to funnel users towards preferred languages, or not. I do know it's made me choose other flavors of Linux when I have a choice.
| [reply] |
Re: Why not include version.pm
by stevieb (Canon) on Mar 25, 2016 at 20:34 UTC
|
RHEL has for quite some time stripped down core (version has been in core since v5.9.0), deeming the default install is a basic, non devel version. A few years ago, they removed CPAN and just as bad, ExtUtils::MakeMaker.
Can you show how you're using the module in order to perhaps write around it?
| [reply] |
|
|
use version;
...
sub checkPerlVer {
my $minVer = shift; # eg '5.12'
my $installVer = `perl -v|grep -E '(v[1-9.]+)'`;
if ($installVer =~ /\((v[\d+.]+)\)/){
#print "match $1\n";
my $reVer = $1;
my $iver= version->parse($reVer);
my $mver= version->parse($minVer);
printf "Minimum Perl=$mver Installed Perl=$iver \n";
if ($mver <= $iver) {
print "OK \n";
return 1; #OK
}else{
print "NOPE\n";
return 0; #NOT OK
}
}else{
print "No version found: <$installVer>\n";
return 0;
}
}
It is always better to have seen your target for yourself, rather than depend upon someone else's description.
| [reply]
[d/l] |
|
|
Ugh. This might return you the version of a different Perl executable than the one your script is run with.
Why not use the $] variable, as documented in perlvar?
print "Running under Perl $]\n";
You will need to change your version check from '5.12' to '5.012' though, because that's what $] will contain. | [reply]
[d/l]
[select] |
|
|
Re: Why not include version.pm
by Tanktalus (Canon) on Mar 26, 2016 at 14:14 UTC
|
And thus, all the more reason to use a separate copy of perl that is under your control, not your distro's control. This also means things like saving off a copy of the modules you need. Stability, predictability, and control. You're no longer at the mercy of a distro that ships modules that have bugs in them (you can apply bugfixes to your private perl), nor in a distro that upgrades a module to be incompatible with you (you simply don't upgrade that module until you can fix your code to match). And you no longer care about which distro is being used - whether it's CentOS, Gentoo, SLES, Debian, Ubuntu, or whatever, you just work. Makes upgrading the distro safer, too, since you won't rely on the system perl, and you know that your stuff will keep working because its perl version is frozen to whatever you've tested.
But maybe that's just me.
| [reply] |
|
|
I agree with you but I think the underlying topic here is installing Perl based software on machines over which you have no control. Having to ship a full version of Perl just to do that is a bit of burden compared to be able to rely on, say, the core features of 5.6/5.8, which really should be stable and available (excepting a couple caveats like CGI) even now.
Python's instability as an install tool (v2/v3 incompatibility) is what soured me on it before I tried anything but installing third party stuff using it. Well, that and the too often rabid community. Hate to hear the same kind of broken experience is in the cards for first time exposure to Perl.
Update: Of course, I just checked and version isn’t core. DERP, it is, checked badly, first in 5.9 :P
| [reply] |
|
|
