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.
