Ignore:
Timestamp:
Jan 10, 2010, 2:49:14 AM (15 years ago)
Author:
broder
Message:

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

File:
1 edited

Legend:

Unmodified
Added
Removed
  • trunk/packages/invirt-dev/README.invirtibuilder

    r2868 r2869  
    335335justify the additional implementation effort or runtime overhead.
    336336
     337Future Directions
     338=================
     339
     340While the Invirtibuilder was written as a tool for the Invirt_
     341project, taking advantage of infrastructure specific to Invirt, it was
     342designed with the hope that it could one day be expanded to be useful
     343outside of our infrastructure. Here we outline what we believe the
     344next steps for development of the Invirtibuilder are.
     345
     346One deficiency that affects Invirt_ development already is the
     347assumption that all packages are Debian-native [#]. Even for packages
     348which have a non-native version number, the Invirtibuilder will create
     349a Debian-native source package when the package is exported from Git
     350as part of the `Build Execution`_. Correcting this requires a means to
     351find and extract the upstream tarball from the Git repository. This
     352could probably be done by involving the pristine-tar_ tool.
     353
     354The Invirtibuilder is currently tied to the configuration framework
     355developed for the Invirt_ project. To be useful outside of Invirt, the
     356Invirtibuilder needs its own, separate mechanism for providing and
     357parsing configuration. It should not be difficult to use a separate
     358configuration file but a similar YAML configuration mechanism for the
     359Invirtibuilder. And of course, as part of that process, filesystem
     360paths and the like that are currently hard-coded should be replaced
     361with configuration options.
     362
     363The Invirtibuilder additionally relies on the authentication and
     364authorization mechanisms used for Invirt_. Our RPC protocol of choice,
     365remctl_, requires a functional Kerberos environment for
     366authentication, limiting its usefulness for one-off projects not
     367associated with an already existing Kerberos realm. We would like to
     368provide support for some alternative RPC mechanism—possibly
     369ssh. Additionally, there needs to be some way to expand the build ACLs
     370for each pocket that isn't tied to Invirt's authorization
     371framework. One option would be providing an executable in the
     372configuration that, when passed a pocket as a command-line argument,
     373prints out all of the principals that should have access to that
     374pocket.
     375
    337376.. _config-package-dev: http://debathena.mit.edu/config-packages
    338377.. _fakeroot: http://fakeroot.alioth.debian.org/
     
    340379.. _grsecurity: http://www.grsecurity.net/
    341380.. _Invirt: http://invirt.mit.edu
     381.. _pristine-tar: http://joey.kitenet.net/code/pristine-tar/
    342382.. _qemubuilder: http://wiki.debian.org/qemubuilder
    343383.. _remctl: http://www.eyrie.org/~eagle/software/remctl/
     
    355395       ``allow_backtracking`` set to ``True`` either.
    356396.. [#] http://kerneltrap.org/Linux/Abusing_chroot
     397.. [#] http://people.debian.org/~mpalmer/debian-mentors_FAQ.html#native_vs_non_native
Note: See TracChangeset for help on using the changeset viewer.