Changeset 2869 for trunk/packages/invirt-dev/README.invirtibuilder
- Timestamp:
- Jan 10, 2010, 2:49:14 AM (15 years ago)
- File:
-
- 1 edited
Legend:
- Unmodified
- Added
- Removed
-
trunk/packages/invirt-dev/README.invirtibuilder
r2868 r2869 335 335 justify the additional implementation effort or runtime overhead. 336 336 337 Future Directions 338 ================= 339 340 While the Invirtibuilder was written as a tool for the Invirt_ 341 project, taking advantage of infrastructure specific to Invirt, it was 342 designed with the hope that it could one day be expanded to be useful 343 outside of our infrastructure. Here we outline what we believe the 344 next steps for development of the Invirtibuilder are. 345 346 One deficiency that affects Invirt_ development already is the 347 assumption that all packages are Debian-native [#]. Even for packages 348 which have a non-native version number, the Invirtibuilder will create 349 a Debian-native source package when the package is exported from Git 350 as part of the `Build Execution`_. Correcting this requires a means to 351 find and extract the upstream tarball from the Git repository. This 352 could probably be done by involving the pristine-tar_ tool. 353 354 The Invirtibuilder is currently tied to the configuration framework 355 developed for the Invirt_ project. To be useful outside of Invirt, the 356 Invirtibuilder needs its own, separate mechanism for providing and 357 parsing configuration. It should not be difficult to use a separate 358 configuration file but a similar YAML configuration mechanism for the 359 Invirtibuilder. And of course, as part of that process, filesystem 360 paths and the like that are currently hard-coded should be replaced 361 with configuration options. 362 363 The Invirtibuilder additionally relies on the authentication and 364 authorization mechanisms used for Invirt_. Our RPC protocol of choice, 365 remctl_, requires a functional Kerberos environment for 366 authentication, limiting its usefulness for one-off projects not 367 associated with an already existing Kerberos realm. We would like to 368 provide support for some alternative RPC mechanism—possibly 369 ssh. Additionally, there needs to be some way to expand the build ACLs 370 for each pocket that isn't tied to Invirt's authorization 371 framework. One option would be providing an executable in the 372 configuration that, when passed a pocket as a command-line argument, 373 prints out all of the principals that should have access to that 374 pocket. 375 337 376 .. _config-package-dev: http://debathena.mit.edu/config-packages 338 377 .. _fakeroot: http://fakeroot.alioth.debian.org/ … … 340 379 .. _grsecurity: http://www.grsecurity.net/ 341 380 .. _Invirt: http://invirt.mit.edu 381 .. _pristine-tar: http://joey.kitenet.net/code/pristine-tar/ 342 382 .. _qemubuilder: http://wiki.debian.org/qemubuilder 343 383 .. _remctl: http://www.eyrie.org/~eagle/software/remctl/ … … 355 395 ``allow_backtracking`` set to ``True`` either. 356 396 .. [#] 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.