* Karen W. Tung <Karen.Tung at sun.com> [2007-09-06 13:36]: > We are in the process of putting together the feature list for the > Distribution Constructor project beyond the prototype release. The > proof-of-concept Distro Constructor has very limited functionalities > as specified our project page > (http://opensolaris.org/os/project/caiman/Constructor/) > > We have come up with the following for the early 2008 release. This > is a very high level list of features. When we come to a more final > list, we will have further discussions about details on each item. > > * From a GUI, the user should be able to select a list of > packages to be included to build a custom distro. > > * From the command line, user provide the Distro Constructor > (DC) with a list of packages. The DC will pull in all other > necessary packages to create a self-consistent installation > image. > > * Given an existing distribution, the DC will create a new > distribution based on addition or subtraction of contents as > specified by the user. > > * Special configurations specified in the GUI or on the command > line can be saved to a file, and the file can be used as inputs > to the DC. > > * The DC release will come with a few predefined "useful" > configurations, which can be helpful to users who want to create > their custom distribution with some minor modification. > > Features not to be included in the early 2008 release, but will be > consider for the future. > > * Create a distribution based on an installed and configured > system. > > > We welcome your comments and suggestions on the above proposed feature > list for our first official release and beyond.
Although I sympathize with the design from interaction perspective, it seems to me that the most important aspect of the DC is in fact the file mentioned in point 4. This lack of this file (or "image descriptor") has already come up in our exploration for pkg(1) in http://blogs.sun.com/sch/entry/pkg_1_a_no_scripting It seems that the image descriptor should be able to describe zones and other systems with degrees of shared components, as well as standalone systems, install/miniroot images, and other common deployments. Of the points mentioned so far: - I agree that the raw installed size of the image is a constraint that belongs in the descriptor. The on-media size makes sense, too, although I think it has to be evaluated via an actual image build. - I agree that summarizing dependencies is not sufficient to determine intent. Tracking explicit requests, either in the descriptor or from operational history, can resolve some cases, but an image-level policy is probably needed. Packaging has to track this information in any case. - I agree with the requests for groups of packages and specific file endpoints as goals for the constructor; I would add service FMRIs as well. - Branding should be isolated to packages first, which may require work in some consolidations (but not in others); how the higher-level components make branding easy can be pursued in parallel. - If you do intend to allow "based on installed *and configured*", then I assume that this feature replaces the flash archive feature? One aspect of the image descriptor I've worried about is whether there's a marshalled form of an install, or whether the descriptor is sufficient to recreate it on its own. (Sounds like not the latter.) Cheers Stephen -- sch at sun.com http://blogs.sun.com/sch/
