1. Stabilize existing codebase (there are a number of stability issues and corner cases that should and must be resolved with pkg_install).
2. Do minor, but meaningful enhancements where required.
   • For instance, add libarchive support to make pkg_install more responsive to failures, and thus reduce wasted time waiting for tar to complete, and also reduce the number of shell calls.
   • Add locking so that multiple copies of pkg_add / pkg_delete can be run in parallel, thus avoiding (or at the very least reducing) potential race conditions as far as modifying installed packages is concerned.
3. Write extensive tests so that we can ensure that the code makes functional sense; many BSD implementations sadly lack tests, and thus we can't be sure that the code actually meets requirements and reacts in meaningful ways.

Development for Phase 1 is taking place at //depot/projects/soc2007/gcooper-pkg_install-enhancements-simplified

After that point, we need to take a step back and evaluate other available solutions out in the BSD community as a whole, or consider whether a wholesale rewrite is worth the time:

• An idea that was kicked around before by jilles@ was a potential rewrite of pkg_install with a scripting language (of some flavor) as the top-level frontend, and then use a C backend to do the actual maintenance tasks. Take for instance apt vs dpkg, or yum vs rpm. This seems to be a good idea, but again – requires some rewrites and fudging around.
• pkg_install for instance has been completely rewritten (for the most part) in NetBSD to use a seemingly more logical structure: http://www.netbsd.org/gallery/presentations/joerg/eurobsdcon2006/pkg_install.html
• libpkg (which I was originally looking at for the 2007 GSoC and abandoned due to time) is another possibility for the base, but the project has been dead for over a year now (maybe because the code was contributed back to DragonflyBSD?): http://libpkg.berlios.de/

Author's Page: Garrett Cooper.