Q about perl 5.12 and included newer port modules.

Jeremy Chadwick 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
probably more:

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.

<soapbox>
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.
</soapbox>

> 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 mailing list