Changeset 2869

Timestamp:

Jan 10, 2010, 2:49:14 AM (14 years ago)

Author:

broder

Message:

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

File:

• trunk/packages/invirt-dev/README.invirtibuilder (modified) (3 diffs)

trunk/packages/invirt-dev/README.invirtibuilder

@@ -335 +335 @@
 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/
@@ -340 +379 @@
 .. _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/
@@ -355 +395 @@
        ``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