Date: Tue, 27 Mar 2007 10:07:55 -0400 From: Vivek Khera <vivek@khera.org> To: freebsd ports <freebsd-ports@freebsd.org> Subject: Re: Managing perl modules Message-ID: <823B9A32-9E8F-4160-ACB7-297E53F11D47@khera.org> In-Reply-To: <20070327081120.GB23454@heechee.tobez.org> References: <20070326234315.GE25691@rescomp.berkeley.edu> <20070327081120.GB23454@heechee.tobez.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--Apple-Mail-3--871219585 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed 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. --Apple-Mail-3--871219585--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?823B9A32-9E8F-4160-ACB7-297E53F11D47>