Managing perl modules

[Vivek Khera]

On Mar 27, 2007, at 4:11 AM, Anton Berezin wrote:

>
> Hmm.  Presumably any method you use except when a module is in the  
> ports
> collection would not work with portupgrade and friends, for a suitable
> definition of "work".
>
> If you want portupgrade and other methods to do the upgrades for  
> you, you
> want the modules in the ports collection.  If you create a port,  
> please do
> not forget to submit it to the ports collection via send-pr, so  
> that it will
> be available to others.
>

Exactly...  no system will survive multiple package managers long  
term.  It is for this reason that for all perl modules on which we  
depend for our production services, we ensure that there exists a  
FreeBSD port.  In fact, I just submitted two more yesterday...

My big issue with bsdpan is that the upgradeability is painful unless  
the name auto-generated just happens to correspond with the name of  
an extant port for the same module.  Much of the time it works, but  
for some like Template::Toolkit, it fails.  Ditto for libnet.

Another problem is that if for example you need a perl module that  
depends on a bunch of others, and many of those do have existing  
freebsd ports, the bsdpan install will ignore those (unless they're  
already installed) and you get bsdpan versions instead of the  
'official' port installed.

It really is better to make a freebsd port for the perl modules.   
More automated tools to do so would be wonderful, but most cpan  
modules only install a handful of files and it is not that much work  
to do it by hand.  See for example the new devel/p5-Gearman port I  
submitted yesterday.  Very simple and a good skeleton for many cpan  
modules.

We use "local" ports for configuration management of our servers --  
we set up a port for each class -- eg, a mailserver meta port  
installs our standard mail server software, a dbserver meta port  
installs the necessary ports for running postgres + replication, etc.