[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: How do you manage Perl modules?



G'day,

"Kris Deugau" wrote:
[...]
> Due to some of the software in Debian stable being really *badly*
> outdated (ie, SpamAssassin), and some just plain missing (ClamAV,
> MIMEDefang, and an assortment of Perl bits), I've set up apt sources
> pointing to backports.org, but there's nothing there for MIMEDefang.
[...]
> 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.
[...]

You have hit the big problem with "stable"; some packages are highly
depended on by the whole distro (libc, perl, etc). Once these get out of
date, you pretty much have to backport the whole distro.

The eternal dilema between "current" and "stable"; do you have lots of
regualar little upgrade headaches, or have very rare big nasty ones, with
your system getting further and further out of date as you put off the pain.
For me "stable" is too stable, "unstable" is too unstable, and "testing" is
a nice compromise.

The reality is software evolves, and your systems are going to have to
evolve with it. Testing's automated "all dependencies met + 2 weeks without
bugs" criteria is a pretty close match to my idea of an ideal distro. The
worst thing missing is supporting and fast-tracking security updates. The
other thing is packages that "upgrade" at a faster than 2 week interval...
they never make it into testing (AFAIK).

> Among other things, I've very carefully made sure that there is NOT a C
> compiler on the new production boxen.  Otherwise, I'd just use CPAN and
> put up with two package management systems instead of one.  :(

If you live in backport land, you will need a system you can build your own
backports on. I don't believe you can get away without it. I suggest a
seperate devel server, that can double as a "before deployment" testing box.

----------------------------------------------------------------
Donovan Baarda                http://minkirri.apana.org.au/~abo/
----------------------------------------------------------------



Reply to: