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 known, 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.
   • Remove the custom Boolean data type with C99 standard bool (#include <stdbool.h>).
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

Determine what useful functionality can be implemented in the time being as Phase 2, (before Phase 3) which would benefit the project and the community as a whole, and/or make the transition to Phase 3 a smoother one.

1. Split up code from previous GSoCs into smaller functional blocks, such that they can be committed back to the project.
2. Write functional tests for new code if said functional tests do not exist.

Other pieces, TBD (contingent upon Phase 1.5).

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 (started during the 2009 GSoC) takes advantage of libarchive and is another possibility for base: http://code.google.com/p/libpkg/
• 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/

1. pkg_delete -f needs fine tuning.
   • -f should overwrite only the dependency checks
   • an new option should be used for removing files which checksum does not match. - didn't reach consensus on this.
   • “portupgrade” used “-f” and so a lot of user modified files get lost. make deinstall does too.

1. pkg_add should by default skip already existing files, and override them only with an option similar to pkg_delete above.

1. Replace @exec and @unexec for config.

Packing lists are clobbered with lines like :

@exec [ ! -f %B/foo ] && cp %B/%f %B/foo
@unexec cmp -s %D/etc/foo %D/etc/foo-dist && rm %D/etc/foo
@unexec rmdir %D/share/foo 2> /dev/null || true

Suggestion by flz: http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/77082

@cpin name : copy if non-existent, copy name from name-dist if name doesn't exist yet.
@rmiu name : remove if unchanged, remove name if name and name-dist are no different.

Maybe consider it with only on instruction:
@config etc/foo etc/foo-dist

Pkg_add will copy if non-existent “${PREFIX}/etc/foo-dist” to “${PREFIX}/etc/foo”
Pkg_delete will remove “${PREFIX}/etc/foo” if unchanged from “${PREFIX}/etc/foo-dist”

Support may be extened to have macros in bsd.port.mk:
http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/75464

1. Replace @exec and @unexec with script infrastructure code and deprecate existing callers.
   • Need to produce prototype to demonstrate effectiveness of the following items:
     1. Quantifiable performance results stating statistically what the difference is on average processing plists without @exec and @unexec in the following cases, with the parsing code enabled and disabled.
     2. Provide an implementation that makes absolute justifiable sense.
   • Need to write up an official proposal noting the change. Reference thread: http://lists.freebsd.org/pipermail/freebsd-ports/2010-March/060239.html (title: `[RFC] deprecate @exec and @unexec in plists in favor of pre-install and post-install scripts').

1. Polymorphic packaging

Many packaging systems today either do single, monolithic packages (FreeBSD is one example), or split the packages logically depending on whether or not there are headers, static libraries, etc, which are used at compile time (non-devel vs -devel packages, see Linux distributions like Debian, Redhat for examples of this methodology). In a world where network bandwidth is cheap', and disk space is more of a premium (this is especially true for embedded systems), or on systems where less files are required on servers, desktops, etc, this would be a potentially major win in terms of software footprint, without having to resort to hacks' using scripts or other methods that would potentially break binary upgrades. We could provide the same level of functionality today for those upgrading binary packages, without having to install the build and patch dependencies, s.t. the amount of disk space being actively used by packages is reduced.

• Need to produce prototype to demonstrate effectiveness of the following items:
  1. Quantifiable performance results stating statistically what the difference between polymorphic packages and non-polymorphic packages.
  2. Provide an implementation that makes absolute justifiable sense.
• Need to write up an official proposal noting the change.

Reference thread: http://lists.freebsd.org/pipermail/freebsd-ports/2010-March/060367.html . Please see the rest of the thread for more details.

Author's Page: Ngie Cooper.