That's curious. Is that because you guys modify the source so it behaves slightly differently or is it because the package isn't built with the correct feature flags?
The pkg system is possibly nice for beginners who are looking for a quick and easy way to get a system up and running in short order.
It is not, however, a particularly good idea in other ways. It is no good at building complicated servers; it spams crap throughout the host's base OS, making it extremely difficult down the road to determine what's been installed. At one point, FreeBSD had three or four different Apache ports, one for SSL, one for (IIRC) fastcgi, etc. And these are moving targets as time goes on.
A few of you here may be aware that I created the first freely available FreeBSD appliance OS, intended to boot off floppy to create FreeBSD-based Xterminals (for X11 window system), and that
evolved into PicoBSD when Andrzej Bialecki took it and generalized it a bit. That was the precursor to NanoBSD, which underpinned FreeNAS in the early days. I've included a few links to convince you that I'm crazy.
Anyways, I have a long history of appliance-ified UNIX systems, and part of this is the idea that the system should not have crap spammed throughout it, which is typically what many BSD and Linux package managers have done. It makes it very unpleasant to identify what has been done to the system.
So instead, I split the system up into a base OS, it'd look familiar to you, except that it is generated by an automated build system from a database of configuration directives designed to make it relatively easy to take a host up to the next release of FreeBSD. This is hardened, firewalled, IDS'd, and secured. This host then sponsors applications, in a root subdirectory (such as /www, /pgsql, /postfix, etc.) where the application is installed from the ground up, only the necessary files; all libraries and dependencies for the app are compiled within the tree and no external links are allowed. Most of these are also jailed, and the environments do not include a /bin/sh, so remote stack smash attacks are really hard, and most other types of attacks fail too.
As for ports, they're marginally useful. Stuff like iperf, kermit, rsync, gmake, etc., are handy to have in the base. Other stuff such as quagga/frr are usually a bit rotted and may need a custom patched port. In any case, the system builder is responsible for both building a consistent system image, and then doing baseline configuration of the generated system for all that pesky stuff that people often forget. The builder is over 300KB of Bourne.
Anyways, it ends up giving you a very clean system design; you might even manage to figure out where stuff is just from df:
Code:
Filesystem 1024-blocks Used Avail Capacity Mounted on
/dev/gpt/rootfs 555036 223436 287200 44% /
devfs 1 1 0 100% /dev
/dev/gpt/usrfs 1120540 640072 390828 62% /usr
/dev/gpt/lclfs 902300 658432 171684 79% /usr/local
/dev/gpt/varfs 1765276 71588 1552468 4% /var
/dev/gpt/homefs 643336 428 591444 0% /export/home/u0
tmpfs 65536 8 65528 0% /tmp
devfs 1 1 0 100% /var/named/dev
/dev/gpt/pgsql 8104668 80096 7376200 1% /pgsql
/dev/gpt/pgsql-c 8104668 4 7456292 0% /pgsql/conf
/dev/gpt/pgsql-d 8104668 41568 7414728 1% /pgsql/data
/dev/gpt/pgsql-l 8104668 4 7456292 0% /pgsql/logs
/dev/gpt/www 8104668 2343400 5112896 31% /www
/dev/gpt/www-c 8104668 508 7455788 0% /www/conf
/dev/gpt/www-d 8104668 44144 7412152 1% /www/data
/dev/gpt/www-l 8104668 752 7455544 0% /www/logs
Just a webserver I happen to be working on setting up.