Mailing List Archive

On Tue, Feb 17, 2004 at 05:35:45PM -0500, Jerrin Kallukalam wrote:
> v2.70 apparantly needs perl 5.6.1, whereas v2.63 needed only 5.5.0.
> What changes are there in spamassassin from v2.63 to v2.70 that would
> require a new perl version?

We wanted to stop having to put in hack kluges for 5.005 to do things that
you can do in 5.6 and later. Various forms of RE, (split)[1] works, etc.

The default MakeMaker in 5.6.1 doesn't require us to do ugly kluges
either... 5.6.0 and previous required us to do a lot of hackery to work
the way we wanted.

--
Randomly Generated Tagline:
It is, of course, written in Perl. Translation to C is left as an
exercise for the reader. :-) -- Larry Wall in <7448@jpl-devvax.JPL.NASA.GOV>

Jerrin Kallukalam wrote:

>> v2.70 apparantly needs perl 5.6.1, whereas v2.63 needed only 5.5.0. =20
>> What changes are there in spamassassin from v2.63 to v2.70 that would=20
>> require a new perl version?

It also came down to the fact that none of the active developers were
running any Perl older than 5.6.1 so we could no longer adequately
support those older revisions. Even Perl 5.6.1 is also now considered
quite old in Perl-land so getting support from upstream for Perl modules
and so forth was getting increasingly harder.

Daniel

--
Daniel Quinlan anti-spam (SpamAssassin), Linux,
http://www.pathname.com/~quinlan/ and open source consulting

>
> It also came down to the fact that none of the active developers were
> running any Perl older than 5.6.1 so we could no longer adequately
> support those older revisions. Even Perl 5.6.1 is also now considered
> quite old in Perl-land so getting support from upstream for Perl modules
> and so forth was getting increasingly harder.

How difficult is to upgrade to a new Perl? Do all the various CPAN modules
and other manually installed modules have to be re-installed into the new
Perl tree, or is there an update option on the install that will handle
this?

It seems that RPM's (from Redhat's up2date for example) interact poorly
sometimes
with CPAN installs. Why is that? What's the cure?

>
> It seems that RPM's (from Redhat's up2date for example) interact poorly
> sometimes
> with CPAN installs. Why is that? What's the cure?

And .... is there a utility that can be run which will check the integrity
of the database/file/directory that Perl uses to keep track of the versions
of modules that were installed, with their actual contents?

Hi Gary, on Tue, 17 Feb 2004 21:22:28 -0800 you wrote:

> It seems that RPM's (from Redhat's up2date for example) interact poorly
> sometimes with CPAN installs. Why is that?

Probably because Red Hat supplies a number of CPAN modules in the
distribution, but they are packaged in the usual way as RPMs. If you are
using package management tools like up2date, then there is an implicit
assumption that you are using package management system-wide. If you have
some stuff package-managed and some stuff not-package-managed, or (worse)
overwrite package-managed stuff with un-managed stuff without removing the
package from your database first, then it's inevitable that trying to do
updates etc. using package management will be unpredictable at best.

Consider what happens if your base distribution includes the CPAN module
Foo::Bar. One day, you decide to update it with the "perl" command line to
a newer version. Now, Red Hat then release a new revision on the older
version. When you run up2date, up2date will have no idea that you have
overwritten the module files manually, and will therefore proceed to
downgrade you back to the "newer-older" packaged version.

> What's the cure?

Be consistent in your use of package management. Either install everything
from source without package management, or install everything as RPMs, but
don't do a mixture. In the case of CPAN modules, either remove all the Red
Hat CPAN RPMs and install everything using the perl/CPAN command line, or
(preferably, so as not to break your package management dependencies for
everything else) not use the perl/CPAN command line and instead install
all CPAN modules as RPMs. There are a number of packages floating around
that will automatically package a CPAN module as an RPM, including
"cpan2rpm", "perlmod2rpm" and (my favourite) "cpanflute2".

I hit the same problem myself a few years ago, at which point I made the
decision to use package management properly, and learnt how to build my
own RPM packages for software that I wanted to build from source. So now
absolutely *everything* on my systems is package managed, which makes
updates/rollbacks/whatever easy, predictable and reliable. You can see
some of the packaging I've put together/used at
http://www.timj.co.uk/linux/rpms.php

Tim

Theo Van Dinter wrote:

>On Tue, Feb 17, 2004 at 05:35:45PM -0500, Jerrin Kallukalam wrote:
>
>
>>v2.70 apparantly needs perl 5.6.1, whereas v2.63 needed only 5.5.0.
>>What changes are there in spamassassin from v2.63 to v2.70 that would
>>require a new perl version?
>>
>>
>
>We wanted to stop having to put in hack kluges for 5.005 to do things that
>you can do in 5.6 and later. Various forms of RE, (split)[1] works, etc.
>
>The default MakeMaker in 5.6.1 doesn't require us to do ugly kluges
>either... 5.6.0 and previous required us to do a lot of hackery to work
>the way we wanted.
>
>
>
I have perl 5.6.0 installed that runs spamassassin 2.63. Can I get
spamassassin 2.70 running on that by installing some additional perl
modules? I dont want to do a full perl upgradation right now because it
would break so many other things. Also, what features/changes in
spamassassin require perl 5.6.1 that can't be done with 5.6.0?
Thanks

On Tue, 17 Feb 2004, Gary Funck wrote:

> How difficult is to upgrade to a new Perl?

"install perl-X.Y.Z" in the CPAN shell will generally take care of it.

If you don't want to clobber your existing installation, you probably want
to set the PREFIX in the makepl_arg conf and/or make sure that UNINST is
*not* set in make_install_arg.

> Do all the various CPAN modules and other manually installed modules
> have to be re-installed into the new Perl tree, or is there an update
> option on the install that will handle this?

I belive that's what the CPAN "autobundle" command is for -- you run it in
your old perl to create the bundle file, then install that bundle after
installing the new perl -- but I've never actually used it.

> It seems that RPM's (from Redhat's up2date for example) interact poorly
> sometimes with CPAN installs. Why is that?

Because RPMs build a database of files and their checksums, and obviously
if you upgrade some of the files by a mechanism outside the RPM system
that database will get out of sync with reality. Also, RPM determines
dependencies by examining that database only, so if you get some modules
from CPAN without ever installing the corresponding RPM, later RPMs won't
discover that the CPAN modules are present. And finally, becuse RPMs may
depend on specific bugs or features of specific module versions.

> What's the cure?

Repeatedly attempt the RPM install until you know that the only remaining
dependencies are for modules you installed with CPAN, and then finish the
RPM install with --nodeps. That's pretty much the same answer for *any*
dependency installed "outside" the RPM system.

Or, abandon RPM entirely for perl, and install everything with CPAN ...
but that sometimes means that other packages that use perl may complain.
There is no perfect solution except to never use anything you can't get
as an RPM.

> And .... is there a utility that can be run which will check the
> integrity of the database/file/directory that Perl uses to keep track of
> the versions of modules that were installed, with their actual contents?

Perl (meaning, CPAN) doesn't really maintain a database other than the
perllocal.pod file, AFAIK. It extracts version info from the installed
.pm files directly. There's an index, but that's of what is available
from cpan.org, not of what is installed.

On Wed, Feb 18, 2004 at 09:01:08AM -0500, Jerrin Kallukalam wrote:
> I have perl 5.6.0 installed that runs spamassassin 2.63. Can I get
> spamassassin 2.70 running on that by installing some additional perl
> modules? I dont want to do a full perl upgradation right now because it

Well, 1) There is no 2.70 anymore. It's 3.0.0 now. :) 2) I think
you probably could get it running fine if you upgraded MakeMaker, but
you'd still need to go editing the SA code to change/disable the 5.6.1
require statements. I don't know if there are other issues between
5.6.0 and 5.6.1. Probably a bunch of bugfixes et al.

--
Randomly Generated Tagline:
Breathe out... slowly... do not gulp. If you do not breathe correctly,
you do not move correctly! Pitiful. I can see the deadly hamburger has
done its evil work. - Chiun in Remo Williams: The Saga Begins