From Fedora Project Wiki
(review doc)
 
Line 5: Line 5:
== Summary ==
== Summary ==


Replace the contents of the scripts/ subdirectory in anaconda with an external tool named lorax that generates the installation images for distribution trees.  Lorax should be flexible enough for use as a standalone program, but capable of easy integration in to pungi and other release engineering tools.  Image contents should be configurable at runtime and not require a rebuild of lorax.
Replace the contents of the scripts/ subdirectory in anaconda with an external tool named lorax that generates the installation images for distribution trees.  Lorax should be flexible enough for use as a standalone program, but capable of easy integration into pungi and other release engineering tools.  Image contents should be configurable at runtime and not require a rebuild of lorax.


https://fedorahosted.org/lorax/
https://fedorahosted.org/lorax/
Line 29: Line 29:
* Anaconda releases are not so strictly tied to rel-eng schedules.
* Anaconda releases are not so strictly tied to rel-eng schedules.
* Ability to change image contents without needing an 11th anaconda build.
* Ability to change image contents without needing an 11th anaconda build.
* Better integration in to pungi rather than the hackjob pile of shell scripts currently in anaconda.
* Better integration into pungi rather than the hackjob pile of shell scripts currently in anaconda.
* No more upd-instroot or mk-images nightmare.
* No more upd-instroot or mk-images nightmare.


Line 52: Line 52:
== Contingency Plan ==
== Contingency Plan ==


Continue using the existing rel-eng scripts that are part of the anaconda project.
Continue using the existing rel-eng scripts that are part of the Anaconda project.


== Documentation ==
== Documentation ==

Latest revision as of 08:22, 8 August 2018

Rework Buildinstall

Summary

Replace the contents of the scripts/ subdirectory in anaconda with an external tool named lorax that generates the installation images for distribution trees. Lorax should be flexible enough for use as a standalone program, but capable of easy integration into pungi and other release engineering tools. Image contents should be configurable at runtime and not require a rebuild of lorax.

https://fedorahosted.org/lorax/ https://fedorahosted.org/lorax/browser

Owner

Current status

  • Targeted release: Fedora 15
  • Last updated: 2010-11-05
  • Percentage of completion: 90%

Detailed Description

The buildinstall scripts are a mess. Cleaning them up would provide benefit to tree composes and more.

Benefit to Fedora

  • Release engineering would have the flexibility to tweak install image contents without depending on a new anaconda build.
  • Joint ownership of image building between installer team and rel-eng.
  • Anaconda releases are not so strictly tied to rel-eng schedules.
  • Ability to change image contents without needing an 11th anaconda build.
  • Better integration into pungi rather than the hackjob pile of shell scripts currently in anaconda.
  • No more upd-instroot or mk-images nightmare.

Scope

Lorax will be a completely separate project and component in the distribution. It will take the place of the scripts/ subdirectory in anaconda. Downstream users of lorax will be pungi and possibly other release engineering tools that come along.

Test Plan

Generate test images outside of the rel-eng process, compare contents with images currently generated by the scripts/ tools. Clean up inconsistencies and problems before having pungi use lorax directly.

After this, provide a patch for pungi so lorax will get used by rel-eng process for Fedora test days.

User Experience

End users are not directly affected by this change.

Dependencies

Lorax itself is not dependent on any other component being delivered, but coordination with pungi will need to be handled so the transition to lorax is not problematic.

Contingency Plan

Continue using the existing rel-eng scripts that are part of the Anaconda project.

Documentation

Release Notes