Upgrade problems to 4.05

[Julian Field]

At 19:25 06/11/2002, you wrote:
>I've been running with 4.00.0a13 ever since that frantic weekend when you
>were spitting out a new alpha every few hours. (You released them all, I
>installed them all, did either of us get any sleep?) At that time I
>couldn't get the ./install.sh to ever work, and you had me uninstalling
>each package, in reverse order, and then installing each package in order.

I have hazy memories of that weekend... Given more hardware, I could build
test systems for other OS's. VMWare helps a lot (my main desktop pc can run
run 3 different OS's at the same time) but it's not a complete solution to
the problem.

>It's been a while, so I decided to catch up again and just grabbed 4.05 to
>try. With that many other installs behind you, I thought I'd give the
>installer another shot. After congratulating me for having the patch
>command and /usr/src/redhat, it gave me this:
>You appear to have 2 versions of Perl installed,
>the normal one in /usr/bin and one in /usr/local.
>This often happens if you have used CPAN to install modules.
>I strongly advise you remove all traces of perl from
>within /usr/local and then run this script again.
>
>If you do not want to do that, and really want to continue,
>then you will need to run this script as
>         ./install.sh ignore-perl
>
>That neatly illustrates the most frustrating thing about my Linux/Unix
>experience. If anyone on earth should know where Perl modules should be,
>it has to be CPAN, right? And if anyone on earth should know where files
>belong on a RedHat system, it would be rpm, right? So how come every
>machine I have ever run more than a week has at least two sets of several
>Perl directories? (Never mind that I have to have two versions of Python now.)
>
>I know, you didn't make this mess. But I certainly don't feel confident
>removing all traces of Perl from /usr/local, and the only trace I see there is
>    mod_perl.pm -> /usr/lib/perl5/site_perl/5.6.0/i386-linux/mod_perl.pm
>which is a link to yet a third location. Is there a risk in running more
>than one copy of Perl things?

It can affect where cpan tries to install things, which may not be where
/usr/bin/perl finds things. The test in my script looks for /usr/bin/perl
and /usr/local/bin/perl, and complains if they both exist.
Try
         cd /usr/local
         find . -name '*perl*' -print
to find potential targets,

>  Is it greater than the risk of running less than one? Or, as seems more
> likely to me, having seven copies of Perl things but none of them is in
> the place that something else wants it to be? As much as I despise
> Microsoft, I at least know where everything goes in a Windows system! </rant>
>
>So, I'm thinking about going back to the familiar routine of removing each
>RPM in turn and reinstallting them one at a time. That way the only thing
>I have to worry about is to restore my MailScanner.conf. (Which reminds
>me, why can't RPM note if a valid conf file is in place and leave it alone?)

RPM does do this, and will leave you with both the new one and your old
one, so you can sort out your customisations.

>Also, I have noticed a major difference in the messages I get when a virus
>is found. When I was running 3.23 I got the headers of the offending
>message, now I get a short summary. Is this a change from MailScanner 3 to
>4, or a change from Kasparsky to f-prot which I made at the same time for
>economic reasons?

This is a configuration option, called something containing "Full Headers"
if I remember rightly.
--
Julian Field                Teaching Systems Manager
jkf at ecs.soton.ac.uk         Dept. of Electronics & Computer Science
Tel. 023 8059 2817          University of Southampton
                             Southampton SO17 1BJ
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.mailscanner.info/pipermail/mailscanner/attachments/20021106/183531d7/attachment.html