Ack! Messy messy problem with PERL and RedHat 7.x

[Numbski]

Okay, here's what happened:

I'm trying to set up a mail server that runs IMAP locally, so that people can use PINE for e-mail, Outlook Express or another GUI mail client, and Web Mail and always see the exact same folders no matter where they connect from. It seemed like a pretty slick setup to me at the time, so I got IMAP running, got PINE and OE configured right. That brought me to WebMail.

I settled on a package called AcmeMail, now on Sourceforge as "Sparkle".

I didn't know Sparkle even existed at the time, so I used the classic AcmeMail package, and followed the instructions to install, which included installing many, many modules from CPAN.

To make a long story short, when I installed RedHat 7.1 on this server, PERL was located in /usr/bin/perl. At some point during the AcmeMail install somehow a second copy of PERL got installed at /usr/local/bin/perl. Both copies co-exist on the machine. The problems (and there are many) generated by this are simple things like wanting to install a module on /usr/bin/perl, but CPAN won't let me because it's installed on /usr/local/bin/perl, but I can't figure out for the life of me how to get rid of that second PERL install and straighten out CPAN so that I just have the one PERL install at /usr/bin/perl again.

I told you it was messy.

 

[Numbski]

Here's a link to the instructions I followed. I suspect the 'install Bundle::CPAN' is where things got fouled up, but after weeks of research I've found no way to straighten this out on my own.

http://www.emuchrist.com/hksilver/acmemail.txt

 

[LightElf]

1) 'kill' both Perl and install one.
2) 'kill' only one Perl and do
cd /usr/local/bin
ln -s /user/bin/perl
?

 

[Numbski]

That's the problem...I don't know how to 'kill' either of them.

 

[Leland123]

Hi,

You need to know which version of perl your system is using by default. On my linux box, I can type the following and perl will return the path to the perl interpreter:

whereis perl

This command didn't work on my windows box running activestate perl, but you can obtain the same thing on any platform with the version command. Be sure and use a capital V for the long comment on your perl version:

perl -V

Pay particular attention to the @INC: statements which show which paths your perl searches by defualt. One of these paths of course must contain the perl interpreter.

Having two version of perl on your box probably will not cause any problems, but you should thing about uninstalling the version of perl that is not set up in your system as the default perl.

Since you are using linux, the whereis perl command should do it for you. You may need to change the "#!/usr/xxx/xxx/perl" statement that begins each script so it points to the perl version your system is using by default; as, any new modules installed will be installed in the directory structure used by your default perl verison and no doubt be in the paths searched as indicated by @INC: statement.

Good Luck
Leland F. Jackson, CPA
Software - Master (TM)

http://www.smvfp.com

Nothing Runs Like the Fox

 

[MikeLacey]

on some systems

'which perl'

instead of whereis

and on others

'whence perl' Mike
michael.j.lacey@ntlworld.com
Email welcome if you're in a hurry or something -- but post in tek-tips as well please, and I will post my reply here as well.

 

[Numbski]

The problem is that I cannot get CPAN to install modules because it think they are already installed.

I want everything back in /usr/bin/perl, but I'm nearly certain redhat is now using /usr/local/bin/perl by default. :-
So that being the case, how do I 'kill' /usr/local/bin/perl and get everything back to normal?

 

[LightElf]

rm /usr/bin/perl
cd /usr/bin/perl
ln -s /usr/local/bin/perl perl

 

[Numbski]

What about all the modules that got installed for that /usr/local/bin/perl install? Is there any clean way to get rid of those? And the support files for perl. That just gets rid of the binary itself, and not all the extra files, right?

Also....you're having me remove /usr/bin/perl that way, not /usr/local/bin/perl. I get the idea though.

 

[Leland123]

Hi,

I'm running RedHat Linux 7.1. I did some checking and the actual perl interpreter on my system is in /usr/bin. I checked my linux's environment setting with the ENV command, and sure enough, /usr/bin is part of my linux's default path statement. Therefore, if I type "perl" from anywhere in the computer, perl will be found in the /usr/bin directory when it is searched.

Type ENV at your command window to see your environment settings.

I also typed /usr/bin/perl -V to see perl's default directory search pattern and got the following:

@INC:
/usr/lib/perl5/5.6.0/i386-linux
/usr/lib/perl5/5.6.0
/usr/lib/perl5/site_perl/5.6.0/i386-linux
/usr/lib/perl5/site_perl/5.6.0
/usr/lib/perl5/site_perl

If you type /usr/bin/perl -V at your command promt and get the same thing I'm getting, then my guess is that your perl installation is O/K.

Most of the modules I have installed appear under /usr/lib/perl5/site_perl/5.6.0/i386-linux but some could be in other places. If you have installed modules, perl should be able to locate them base on its default search paths per the @INC: statement. Leland F. Jackson, CPA
Software - Master (TM)

http://www.smvfp.com

Nothing Runs Like the Fox

 

[Numbski]

So, what just run rmdir on everything that shows up in @INC, then

ln -s /usr/bin/perl perl

?

Because right now it thinks the default install is /usr/local/bin/perl, but that's not the way it was when I began, it was /usr/bin/perl.

What a mess...

 

[Numbski]

Ugh, I did just that.

What I wound up doing after that is thus:

rpm -q perl

Took that listing then did

rpm -e perl* (whatever was returned)

on all entries.

THEN got the latest PERL rpm, downloaded then did

rpm -i perl*

After that, then did

perl -MCPAN shell;

I found that this wasn't working because it couldn't find libnet, so i had to manually download a few files to *just* the right places in /root, then it took off installing Bundle::CPAN again. I'm going through it now, and I'm now making certain that it installs to /usr/bin

Oi! Note to everyone DON'T TRY THIS AT HOME KIDS!

 

[Numbski]

Okay, update.

Basically, when I attempted to run the CPAN shell, it wanted me to update Bundle::libnet, so I typed

install Bundle::libnet

It grinds and compiles for about an hour, and then I get this:

make[1]: Leaving directory `/root/.cpan/build/perl-5.6.1'
/usr/bin/make install -- OK
Running make for J/JR/JROGERS/Net-Telnet-3.02.tar.gz
Can't locate object method "new" via package "MD5" at /usr/lib/perl5/5.6.0/CPAN.pm line 3440.

k, so I'm thinking at that point that maybe something's wrong with MD5.

install MD5
MD5 is up to date.

hmmm...

force install Bundle::libnet

Running make for G/GS/GSAR/perl-5.6.1.tar.gz
Can't locate object method "new" via package "MD5" at /usr/lib/perl5/5.6.0/CPAN.pm line 3440


Eh????

Any ideas?

 

[Numbski]

bump

 

[Guest_imported]

Hey dood I feel your pain, I am in the exact same situation. Certainly more people have had the same problem - installing RH 7.2 and then installing perl modules with CPAN will get you there, quickly.

If I could just fix that damned @INC then it seems like things would be cleared up. The problem was clear in your last post -

Running make for ...**5.6.1**
Cant locate at ... **5.6.0**

I have been told that you should always use RPM's whenever possible on Redhat, esp to update something that was in the default installation. I noticed that ActiveState has a 5.6.1 RPM, but this is called ActivePerl. Installing this to fix the problem would probably make things worse? :>

Do we have to wait for Redhat to put together a 5.6.1 RPM? Or is there some way to get rid of 5.6.0 and fix that damned @INC?

 

[Guest_imported]

Found a small clue at this link:

http://www.unc.edu/~alangley/INLS183/assgn7.htm

So here's what I did.

su -
cd <...>/.cpan/build/perl-5.6.1
make install
ANSWER YES to the question about &quot;Do you
want /usr/bin/perl to be the same as
/usr/local/bin/perl?&quot;
perl -v
5.6.1, yeah!

Does this work for you?