Add a section on "Future Directions" for the Invirtibuilder.

svn path=/trunk/packages/invirt-dev/; revision=2869

diff --git a/README.invirtibuilder b/README.invirtibuilder
index 6ba5124..0a853bf 100644 (file)
--- a/README.invirtibuilder
+++ b/README.invirtibuilder
@@ -334,11 +334,51 @@ or by using a more isolated build mechanism
 (e.g. qemubuilder_). However, we decided that the security risk didn't
 justify the additional implementation effort or runtime overhead.
 
+Future Directions
+=================
+
+While the Invirtibuilder was written as a tool for the Invirt_
+project, taking advantage of infrastructure specific to Invirt, it was
+designed with the hope that it could one day be expanded to be useful
+outside of our infrastructure. Here we outline what we believe the
+next steps for development of the Invirtibuilder are.
+
+One deficiency that affects Invirt_ development already is the
+assumption that all packages are Debian-native [#]. Even for packages
+which have a non-native version number, the Invirtibuilder will create
+a Debian-native source package when the package is exported from Git
+as part of the `Build Execution`_. Correcting this requires a means to
+find and extract the upstream tarball from the Git repository. This
+could probably be done by involving the pristine-tar_ tool.
+
+The Invirtibuilder is currently tied to the configuration framework
+developed for the Invirt_ project. To be useful outside of Invirt, the
+Invirtibuilder needs its own, separate mechanism for providing and
+parsing configuration. It should not be difficult to use a separate
+configuration file but a similar YAML configuration mechanism for the
+Invirtibuilder. And of course, as part of that process, filesystem
+paths and the like that are currently hard-coded should be replaced
+with configuration options.
+
+The Invirtibuilder additionally relies on the authentication and
+authorization mechanisms used for Invirt_. Our RPC protocol of choice,
+remctl_, requires a functional Kerberos environment for
+authentication, limiting its usefulness for one-off projects not
+associated with an already existing Kerberos realm. We would like to
+provide support for some alternative RPC mechanism—possibly
+ssh. Additionally, there needs to be some way to expand the build ACLs
+for each pocket that isn't tied to Invirt's authorization
+framework. One option would be providing an executable in the
+configuration that, when passed a pocket as a command-line argument,
+prints out all of the principals that should have access to that
+pocket.
+
 .. _config-package-dev: http://debathena.mit.edu/config-packages
 .. _fakeroot: http://fakeroot.alioth.debian.org/
 .. _git-buildpackage: https://honk.sigxcpu.org/piki/projects/git-buildpackage/
 .. _grsecurity: http://www.grsecurity.net/
 .. _Invirt: http://invirt.mit.edu
+.. _pristine-tar: http://joey.kitenet.net/code/pristine-tar/
 .. _qemubuilder: http://wiki.debian.org/qemubuilder
 .. _remctl: http://www.eyrie.org/~eagle/software/remctl/
 .. _SIPB: http://sipb.mit.edu
@@ -354,3 +394,4 @@ justify the additional implementation effort or runtime overhead.
        create new tags for builds on pockets with
        ``allow_backtracking`` set to ``True`` either.
 .. [#] http://kerneltrap.org/Linux/Abusing_chroot
+.. [#] http://people.debian.org/~mpalmer/debian-mentors_FAQ.html#native_vs_non_native