Q about perl 5.12 and included newer port modules.
freebsd at jdc.parodius.com
Mon Sep 20 16:14:48 UTC 2010
On Mon, Sep 20, 2010 at 11:07:33AM -0400, Michael Scheidell wrote:
> I noticed, while looking at the SpamAssassin Port
> (p5-Mail-SpamAssassin) that there are at lease one set of pm
> dependencies that would pull in obsolete (older) ports versions that
> would overwrite newer, built in modules in perl 5.12.
> As the port maintainer for p5-Mail-SpamAssassin, I am looking for
> ideas, policies, procedures for handling something like this.
> For the SA port, I can always use if/else statements in the run and
> build dependencies, looking for PERL version, BUT:..... that only
> handles the immediate issue.
First and foremost, thank you for maintaining p5-Mail-SpamAssassin!
This is a port we rely on heavily given our hosting role. :-)
As I understand it, perl version checking mostly solves the issue. The
way it works in pretty much every other port is: you check PERL_LEVEL.
Yes, it can get hairy and out of control depending on how many
dependencies are required, but the most PERL_LEVEL checks a single port
Makefile has is 4 (devel/p5-CPANPLUS). That rough number comes from:
grep -r -c PERL_LEVEL /usr/ports | sort -t: -k2 -n | tail -20
I say "mostly" because there are two one-off cases I can think of, and
1) If the module version that comes built-in to perl 5.12 doesn't work
with SpamAssassin, in which case you need to open up a bug report with
them to get it fixed upstream + provide a patch (in
p5-Mail-SpamAssassin/files) to temporarily fix the issue.
2) Situations like the RUN_DEPENDS entry for Time::HiRes. I question
the mandatory nature of this dependency when the user has something like
perl 5.10.2 or perl 5.12 installed. I assume this was done because the
version included with perl, at one time, was broken/outdated -- was this
ever fixed? If so, PERL_LEVEL "fix" it.
Welcome to the problem with software that ends up pulling in a zillion
dependencies. I have a very young colleague who a few years ago used to
tell me "why do you care about the large number of perl module
dependencies? You're just whining". Fast forward to a few weeks ago,
where I caught him complaining about how many his system had installed
on it. This model of "creeping featurism" is becoming more prominent
today; for sake of example, why does Apache 2.2 now require Python to
build? Sometimes I feel like I'm the only person who questions such
design choices in software these days.
> Either case, this does go beyond just on perl port
> (p5-Mail-SpamAssassin)? or should we update any pm's that are older
> than 5.12?
I can assure you the latter point won't fly -- there are many perl
modules which break backwards compatibility (or start emitting warnings
when used with newer perl) when a new version is released. Meaning:
version 2.598 is not necessarily better than version 2.711.
If there are a limited number of these scenarios, it would make most
sense for a new port to be created for that specific version of the
module and port Makefiles updated to refer to it.
| Jeremy Chadwick jdc at parodius.com |
| Parodius Networking http://www.parodius.com/ |
| UNIX Systems Administrator Mountain View, CA, USA |
| Making life hard for others since 1977. PGP: 4BD6C0CB |
More information about the freebsd-ports