Re: How do you manage Perl modules?
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: