This page is intended to become the main place to look for developer information on Boots. We'll start with a simple scratch pad.

Content and Structure

Boots, as a project, is proposed to have two parts: A Conary-encapsulated mirror of Fedora proper, and a derived remix, which is Boots per se.

Conary-Encapsulated Fedora Mirror

This mirror will be an exact and complete mirror of specific versions of x86 and x86_64 Fedora into a Conary repository, with no changes at all.  These packages will be the actual RPMs that comprise the specific Fedora version, encapsulated inside Conary package metadata but entirely unaltered.  (These packages are installed and maintained on the system by RPM; the Conary encapsulation allows Conary to orchestrate RPM's actions.)

This is a mirror of Fedora.  It is not a remix.  Not only does it include all the Fedora content (including the trademark packages), but also no other content is added.  It is merely wrapped in Conary metadata, in essentially the same way that a yum repository wraps the RPMs in yum metadata.  (The Conary metadata is much richer, but that's not an important distinction.) This mirror is an essential prerequisite for Boots, but it is not itself Boots.

1. Updates will be imported regularly from upstream Fedora. rPath has open-sourced mirrorball, an import tool intended for this and similar purposes. This is the code that rPath uses to maintain (primarily automatically) up-to-date imports of SLES 10, SLES 11, CentOS 5, and Scientific Linux 5 as maintained platforms, and Ubuntu Hardy as a proof of concept. rPath intends to use this code to maintain additional platforms in the future, and expects to do further development of this code. It is available under the same license as Conary (the CPL). This tool will be used to automate packaging upstream updates as Conary packages.
2. Each new Fedora release will be imported on its own label. (Unlike Foresight Linux, Boots is not a rolling release.)
3. Bugs in the Conary-encapsulated Fedora mirror should be filed in the BOOTS project in the Foresight Issue Tracking System (FITS). Note that bugs present in upstream Fedora will be redirected to the Fedora bugzilla and closed in FITS.

The conary-encapsulated Fedora mirrors are proposed to be provided at the label boots.rpath.org@fedora:fn (so Fedora 13 would be on boots.rpath.org@fedora:f13).

Boots per se

Boots per se is a remix, built on top of the Conary mirror of Fedora.

Boots is proposed to be as faithful as possible to the practices of the upstream platform, within the constraints of being packaged for Conary using Conary best practices.

1. Boots is primarily a binary derivation of the Conary mirror of Fedora, with packages modified or rebuilt from source as necessary to work as a Conary-based distribution (including, for example, changing PackageKit to use the Conary backend).
2. It will contain essentially all the packages from Fedora, not a desktop subset. "Essentially all" because some must be left out for trademark compliance; others may be left out if they are known to not function. The RPMs will be from the RPM capsule Fedora mirror Conary repository.
3. Functional SELinux support is not a project requirement.
4. Conform to the trademark compliance rules of the upstream Fedora project.
5. Anaconda, which may or may not be provided for any specific Boots version, is to be based on or related to the rPath Linux or Foresight Linux version, which may not be related to the latest Fedora upstream. (Among other reasons, we need "appliance installer" tarball support. Boots developers interested in the installer are encouraged to work to merge necessary support into upstream Anaconda, and/or port more recent upstream Anaconda to have any necessary features. Furthermore, this work can and should reasonably be shared between Foresight Linux and Boots.)
6. Bugs in Boots should be filed in the BOOTS project in the Foresight Issue Tracking System (FITS). Note that bugs present in upstream Fedora will be redirected to the Fedora bugzilla and closed in FITS.
7. Boots version numbers will follow Fedora version numbers, and the labels will as well: boots.rpath.org@boots:fn (e.g. boots.rpath.org@boots:f13).

Note that Anaconda support is not required. It will be possible to install upstream Fedora, then bring the system under Conary management, and then migrate the system from vanilla Fedora to a Boots install by using the "conary migrate" command.  The existence of the complete Fedora mirror is critical to being able to complete this migration.  Note that this migration will not only add the packages that are part of Boots but not part of the initial Fedora install, but also will remove any packages that are part of the initial Fedora install but not part of Boots (such as the Fedora trademark packages).

One point that deserves significant discussion is that "essentially all" means that RPM will be included as part of Boots per se, even though it is Conary-managed, as this is required for RPM capsules. Note that running the rpm command could break a running system, since Conary will be unaware of the changes made by the RPM command. The idea is that installing something with rpm and overwriting Conary-managed content is really no different than doing so with tar. That is to say, the rpm command is on the installed system. If you choose to use it to install packages that conflict with Conary, you broke your system, and you get to keep both pieces. It is like tar that way--if you choose to use tar to unpack a tar archive over existing files managed by Conary, you broke your system, and you get to keep both pieces. Similarly, if you use unzip to unpack a zip file over existing files managed by Conary, you broke your system, and you get to keep both pieces. (That warning provided, Conary does have significant repair facilities available, and specifically can recover from using RPM to modify the installed system set in many circumstances.)

Anyone who wants to deviate more significantly from Fedora should do so by making a derivative of Boots, or a separate derivative of the encapsulated Fedora mirror, whichever is easier for them. Boots should include an rPath platform-definition package to make that feasible. We should expect Boots to be used to create derivatives, just as this is expected for Foresight Linux, rPath Linux, and the various platform imports maintained by rPath for use in rBuilder and rBuilder Online.

The goal is not to do extensive QA beyond what is done upstream for Fedora. Bugs in Fedora will generally reproduce in Boots. The goal is to automate as much as possible getting content from Fedora's RPMs to Boots consumers. Thus, a "tagline" for Boots might be, "It boots, ship it!"

An alternative set of labels may be made available as part of boots that are a full source rebuild of some subset of the packages, as some developers have expressed interest in doing this.

Boots preliminaries

• Completing Conary modifications for efficient import (repository) and precise representation (Capsules) of the RPM-packaged Fedora content (rPath developers) [Sufficiently complete]
• Developer mailing list (using foresight-devel@lists.rpath.org by invitation until/unless this becomes inconvenient for Foresight Linux developers)
• Complete list of developers volunteering to help
• Anaconda refresh (Mark__T and mull) [Not required, but would be nice]
• Mirrorball Configuration (mkj and elliot)
• Adding support for parsing Fedora Updates to mirrorball (Bertrand Juglas / bertux)