Re: How do you manage Perl modules?
I'm in similar situation, last night I installed spamassassin & razor from
backports.org. It seems to be working ok....
Fortunately for me, I don't have to worry about being forward compatible
with an existing Bayes db.
For you a (maybe painful) alternative to going to unstable is to discard
your older Bayes and automatic whitelist files.
Another alternative is to dump at least your whitelist to text, and then
script an import....
btw, the first time you ran sa-learn did you get an error?
something like like:
"whatsits_foo.a not in @INC --needed for Digest::SHA1"
I tried to make the problem go away with apt-get but got something like:
"blah is already the current version"
I succeeded in making the problem go away w/
/usr/bin/perl -MCPAN -e install Digest::SHA1
#############
On Sun, 8 Feb 2004, Craig Sanders wrote:
> On Fri, Feb 06, 2004 at 05:41:18PM -0500, Kris Deugau wrote:
> > However, I've just discovered that there's also a bad version mismatch
> > between the "default" libdb version used by DB_File in RedHat, and the one in
> > Debian (db3 in RedHat vs db1 [I think] in Debian). I also discovered that
> > this has been included as a part of the monolithic perl-5.6.1 package, and I
> > *really* don't want to go anywhere near backporting that myself or using a
> > third-party backport.
> >
> > I discovered this in trying to get the SA2.63 install (from backports.org) to
> > recognize the ~40M global Bayes dbs and per-user AWL files; instead I
> > discover pairs of .dir + .pag files for AWL (which I vaguely recall are an
> > artifact of db1) and SA won't open the existing bayes_* files.
>
> sounds like you've run into a reason to upgrade to unstable.
>
> you have three choices:
>
> 1. backport perl 5.8.x and libdb4 and all associated modules and other
> packages.
>
> 2. try to find a backports archive where someone else has done the same.
>
> 3. point sources.list at unstable and either 'apt-get install' perl and
> other packages, or 'apt-get dist-upgrade'.
>
> choice 1 is a lot of work.
>
> choice 2 doesn't really offer any benefits over just upgrading to 'unstable',
> or upgrading certain packages to their 'unstable' versions.
>
> choice 3 will result in the least problems, and will be better tested - there
> are far more people using unstable than there are using backports of perl.
>
> > Is there something like cpan2rpm or cpanflute for Debian? I'd like to
> > pull in current versions of Perl modules
>
> dh-make-perl can fetch a package from CPAN and produce a working package that
> is good enough for local use (but not "polished" enough to upload to debian for
> re-distribution).
>
> > (or even just recompile the
> > stable version against different libs).
>
> this is always an option. it's called 'back-porting'. download the debianised
> source from unstable (along with any build dependancies) and build it.
>
>
> > I *could* hack together some bits to force db3 to work by building on
> > RedHat, and using alien to install... but that's just plain ugly and as
> > I've already discovered it *will* break because of differences in how
> > RedHat and Debian handle the core Perl install and addon modules.
>
> really, upgrading to 'unstable' will be the least-hassle option.
>
> 'unstable' means that the entire system is in flux, that it changes constantly. it
> does not mean that the packages in it are unreliable.
>
> craig
>
> ps: i've been running ALL of my production servers on 'unstable' since 1995.
> i upgrade them semi-regularly. no major problems.
>
>
>
Reply to: