Date: Mon, 20 Sep 2010 09:14:45 -0700 From: Jeremy Chadwick <freebsd@jdc.parodius.com> To: Michael Scheidell <michael.scheidell@secnap.com> Cc: mm@FreeBSD.org, freebsd-ports@freebsd.org Subject: Re: Q about perl 5.12 and included newer port modules. Message-ID: <20100920161445.GA32139@icarus.home.lan> In-Reply-To: <4C9778B5.90408@secnap.com> References: <4C9778B5.90408@secnap.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB |
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20100920161445.GA32139>