OpenSolaris Distribution Constructor Project SketchPad

From Genunix

Some Distribution Constructor like tools in Linux:

some notes from bart:

1) We should explore mechanisms to ensure that the filesystem laid down during initial image construction is the one that gets installed on the target drive; the current scheme seems fragile and subject to accidental inclusion of LiveCD artifacts, as evidenced by the inclusion of /jack in Preview 1. You may wish to consider using zfs in the following way for live CD: 

 1) lay down an image on file backed zpool that contains exactly what you want using on the
 target system using IPS
 2) snapshot zpool
 3) perform whatever modifications are necessary for the liveCD
 4) generate a microroot for CD, and arrange for the file containing the pool to be on CD
 5) during boot, use zpool on CD as RO zfs filesystem, and add ramdisk stripe to allow writes (minor zfs mods needed)
 6) while installing, ZFS send from snapshot to target filesystem(s).


2) IPS doesn't do patching; a "patch" is a later revision of the package(s) in question.

3) Why would you support multiple packaging systems?

4) IPS is designed to work w/ a repository, either remote or local. If you want to pick and choose, you need to work w/ a repo, not w/ a canned cpio archive.

5) IPS provides a general purpose filtering mechanism to select architecture, docs, developer, etc. You may wish to use this to provide user control of content w/o having to select packages.

Thoughts about high level design: Inputs: metaclusters/packages or equivalent, List of authorities to search for these items on, What type of distribution to create, What type of desktop to include, for microroot: 32, 64 or both. Do we want to allow the user to specify a size limitation? How important is it to allow the user to customize this? The microroot is really fragile so maybe this isn't important? i.e. if we have time only Outputs: types of distributions: CD/DVD + live, USB, netinstall


Some thought should be put into what (if any) parts of the install code we can leverage.

Dependency checking.... will IPS do what we wish?

The ever popular : What language? Someone should start looking into the pros and cons of the different options once we know what we're doing.

Are we going to support different packaging systems? Maybe this answer is different for March v.s. a later release.


Contents

[edit]

Some thoughts from Jack

  • Format of our initial meeting:

Most important: set the scope of the project. What are the goals for March and beyond?

- For March, we have something nice, extensible and supportable, but maybe not with all desired features - Brainstorm a list of features, then put their development in proper order based on what we can deliver and dependencies of features on each other. - What can be left out for later? Is there anything easier to do now rather than later, or which will make other things easier to do now rather than later?

What kinds of milestones can we use to mark our progress along the way?

We need to spend lots of time designing, so we don't end up reimplementing things down the road.

  • Some package selection ideas:

IPS: if not already there, IPS needs to have categories and maybe subcategories for packages. - to be able to group them by the distro constructor for installation. Note: User can select different categories with Fedora and Ubuntu constructors.

Add more fine-grained control on a package by package basis? Tedious, but space on a CD is limited. If we assume DVDs will be distro media, then package by package granularity is not as much of a requirement, as there is more space.

In constructor screen where categories are selected, add a place to fetch a custom package. Pkg must be in IPS format and accessible. DC can look at its list of dependencies and bring in necessary packages. (Maybe package could be in its own repository, which would leverage the IPS tools in sanity checking the package itself.)

  • Other customization considerations:

Will adding patches as part of the process be included? (It was part of Dave's Caiman Arch document... (Patching module)) How much customization should we allow after packages are installed? User-supplied scripts?

  • Some repository ideas:

When listing repositories, get the list from an online source from Sun, in case new repositories are added, some are removed, etc.

Should also let users specify their own repository in addition to the list of repos from Sun.

How to make sure the whole repository is in sync? Trouble if repo is updated while someone is pulling from it. Maybe clone the repository, update the copy and switch a link to it so newest users will get new repo. Existing installers will remain on old repo for the duration of their install to insure the repo stays consistent.

Each repo to have its own list of supported categories (built automatically from the packages it has), and have distro constructor fetch the category list from the selected repository. Keeps the cat list in sync with the packages. Also makes it easier for third parties to host their own repository with their own packages as their own custom cats will be automatically displayed.


[edit]

Comments from Stephen

  • DC must use a description that can be shared by other "realizers" that create images. That is, a set of goals that is transformed into a LiveCD for i386 (or SPARC), a zone, a virtual machine image, etc. These latter cases ("substrates") are more important for enterprise users than the LiveCD.
  • Installable versus runnable distros should be specified by different goal packages, not by greatly different substrate logic.
  • Strict dependency resolution (as provided by incorporations) eliminates "in sync" repository issue above.
    (What is meant by "provided by incorporations"? Incorporations are a type of dependency in pkg(5) that carries both a minimum version and a constraint on version change. A constraint on version change can restrict right down to a specific timestamp of a package, or up to "anything goes" via the null constraint.)
  • Implementation requirements appear to include easy HTTP access, integration with pkg(5), potentially use of XML, invocation of system commands. Various high-level languages seem appropriate. Integration with constructor GUI appears to be a significant factor.
[edit]

Comments from Karen

I think there are 3 major steps in constructing an image: 

    1) Specifying the details of what the image need to contain.  For example, 32 or 64 bit or both, 
       sparc or x86, what packages/features to include, size of the resulting image...etc..
    2) Based on the requirements specified in step 1, retrieve the actual bits and lay them on disk.
    3) Depending on what kind of resulting image needs to be created, perform additional
       modifications to the bits on disk, and generate the resulting image.

I think step 1 and step 2 are common among all projects that want to use the Distro Constructor. Step 3 is where all the differences will lay. Different output formats require different "post processing" to the bits. When we design the overall architecture of the Distro Constructor, we want to make it easy/possible for the user to have their own customizations done to generate the resulting image they need.

We need to decide what kind of images the Distro Constructor can produce. Would our design only allow a certain set of output, or we would allow any type of output. The pros and cons of supporting any arbitrary output image vs. a specific set of image should be discussed.

[edit]

Comments from dminer

  • DC needs to recapture some of the developer productivity features that were lost in the translation from Live Media's build scripts, such as leveraging of ZFS snapshots in order to provide incremental builds. It also needs to provide improved error reporting; finding build errors right now requires too much combing through logs.
  • There is a dependency between the installer and the media layout for live CD's. In particular, the transfer module needs to be intimately aware of the layout of the media if the installation is a replication of the CD bits, such as in Indiana. Ways of addressing this (parameterized transfer module, or differentiated transfer modules corresponding to layouts) need to be addressed in the design.
  • Better approaches to handling pre-configuration tasks such as Gnome's postrun need to be designed. chroot seems to be an insufficiently strong fence (note rtc's effects on build system in current implementation), and it imposes a requirement to have only limited incompatibilities between the build system and the system being generated.
Retrieved from "http://www.genunix.org/wiki/index.php/OpenSolaris_Distribution_Constructor_Project_SketchPad"