This proposal was approved, and the content on this page is maintained only for historical purposes. Please see the Boots page for the latest on Boots.

Introduction

On August 14, intending to focus discussion, I wrote a now infamous suggestion that Foresight consider rebasing on a binary import of Fedora. I did not seriously intend that this be done; it was a thought exercise. While this did create the platform for discussion that I intended, it also created a lot of noise and heat because it was taken seriously by people outside the foresight development community. Among other things, the discussion made clear certain specific value that Foresight developers and users derive from Foresight moving to a full rebuild from source code of the entire core operating system. For example, Martin Bähr eloquently pointed out that any package that is imported from a binary would create an additional burden to anyone who wanted to fix a bug; but if a package is built from source with Conary in the first place, fixing a bug is very easy. António pointed out that part of Foresight's value has been the fact that it is consistently built from the ground up with Conary from source, which provides both a clear audit trail and the only effective way to update large amounts of software at the same time and expect it to continue to work in a rolling fashion.

It is my opinion that the discussion that followed this discussion has helped to re-energize the Foresight development community.

It also became clear that a number of Foresight developers (and a few others who are not Foresight developers) were interested in a binary import of Fedora RPMs into a Conary repository for a variety of reasons. After I was contacted by multiple people with offers to help, I formulated a proposal that (this time) I meant seriously.

Boots

Following the Fedora Trademark Guidelines, we cannot call a product created by adding Conary and related tools to Fedora, repackaging Fedora RPMs as Conary packages, and importing the whole set into a Conary repository, by the "Fedora" trademark. However, we can (and should) indicate that it is a derived work by using the Secondary Mark in association with the main name of this project. For a variety of reasons (see "pump", a BOOTP server for one example) I have proposed "Boots, a Fedora Remix".

There is enough interest in Boots that it will be created. The question for the Foresight Council is whether to adopt Boots organizationally as a sub-project. There are two main classes of reasons for the Foresight Council to consider adopting Boots:

1. Organizational simplicity and clarity: There is strong overlap between developers interested in contributing to Foresight and developers interested in contributing to Boots, and in many cases development work overlaps and is likely to continue to overlap. These developers wish to work in concert with Foresight; strengthening it and not damaging it. To be organizationally connected makes this intention clearer externally.
2. Utility to Foresight: Ignoring the original (humorous) binary rebase proposal, Boots as a stand-alone distribution has direct value for Foresight.

In order to make it reasonable to evaluate this proposal, I will first describe what Boots is intended to be, and then describe how such a project would have value to Foresight.

Others

Boots is not the only potential import to reasonably live as an organizational sub-project of Foresight. It is merely the one I am interested in participating in building. I would suggest that this proposal be understood as a specific instance of a suggestion for importing other OS bases for various reasons, such as more direct comparison for debugging. I further suggest that each such import be evaluated on its own merits.

Content and Structure

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

1. Boots is primarily a binary import, with packages modified or rebuilt from source as necessary to work as a Conary-based distro (including, for example, changing PackageKit to use the Conary backend).
2. Full import of essentially all RPMs that are part of 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 but generally we'll import packages even without converting RPM scripts to tag scripts, and then add custom tag scripts where necessary to make packages work correctly on a corrective basis, in order to make more useful progress earlier and more quickly. (Also, "all" refers at this time only to x86 and x86_64, though this may change given sufficient developer volunteerism.)
3. Updates will be imported regularly from upstream Fedora.
4. Each new Fedora release will be imported on its own label. (Boots is not a rolling release.)
5. SELinux support is not contemplated for the forseeable future.
6. Conary tag scripts will be used, not RPM package scripts or triggers.
7. File conflicts resolved via dependencies rather than shared files.
8. Trademark compliance relative to upstream trademark requirements.
9. Anaconda is (based on?) the rPath Linux or Foresight 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 and Boots.)

One point that deserves significant discussion is that "essentially all" means that RPM will be included as part of Boots, even though it is Conary-managed; even though running the rpm command could break a running system. 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's 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. (More detailed discussion of the benefits of RPM being included on the system are available in the discussion thread.)

Anyone who wants to deviate more significantly from Fedora should do so by making a derivative of Boots. 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, 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.

Utility to Foresight

Focus: Foresight Linux is a desktop OS. Part of what makes Foresight relevant is that the Foresight view of the OS extends all the way down through the OS to the kernel. Another is that Foresight is absolutely not a server OS; tradeoffs between desktop and server usage are (rightfully) consistently made in favor of desktop utility and ease of use. This does mean, however, that the occasional use of a few server-oriented packages for hybrids is a distraction and is not generally maintained well. Because it has been separately proposed that Foresight use the Fedora toolchain, considering Fedora to be upstream for the compiler, C library and other related tools, having Boots available allows Foresight developers to properly reflect package requests for server programs to Boots and expecting the hybrid to work. Therefore, Boots could help provide development focus to Foresight.

Debugging: Since I originally proposed Boots, many issues have taken longer to debug because an easy comparison to another distribution is not available. Given two similar RPM-based or similar dpkg-based distributions, it is fairly easy to test to see whether a problem is unique to a single OS by installing the packages from another distribution. This is harder when no closely-corresponding distribution is built with Conary. Boots would enable "conary update brokenpackage=boots.rpath.org@boots:f11" for quick testing. It would also enable quick binary comparison with "conary rdiff brokenpackage=boots.rpath.org@boots:f11--foresight.rpath.org@fl:2" (it was noted, as a specific example, that a simple brasero packaging bug took a few hours to track down but would have been resolved in about a minute if this conary rdiff command had been available).

Differentiation: There have been repeated calls within Foresight for a fourth label which provides time-based rather than rolling releases of Foresight content. This has clearly been outside not only the initial purpose of Foresight but also outside the interests of the main contributors and the scope of the available effort. I posit that the reason for this pressure in the past has been that Foresight has been the only Conary-based desktop distribution, so all desktop users who desire a Conary-based desktop distribution, whatever their update preference, have used Foresight, and desired that Foresight fit their schedule and preferences. If Boots is maintained following the rapidly-updated but time-based releases of Fedora, users who desire a time-based release can use Boots, allowing Foresight to roll more quickly with new software releases, regaining its position as a first provider of interesting new technology.

Feasibility

Finally, it is appropriate to consider the long-term feasibility and viability of Boots. The best measure I can provide for likely long-term success is to list the resources that have been made available for building Boots.

1. 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).
2. I have (personally, not speaking as an rPath employee) provided a 750GB hard drive and optimized the "fdev" build machine for faster building in support of using this system for the import process.
3. rPath will run a boots.rpath.org repository appropriately tuned for this use, maintained similarly to foresight.rpath.org. (I suggest a separate repository merely to reduce contention and make it possible to migrate them separately if necessary to handle load/space issues.)
4. rPath has recently modified Conary specifically to increase repository performance for the kind of commit traffic we have experienced while implementing other imported platforms.
5. Multiple developers, inside and outside of rPath, have offered their own time to help maintain this import. I am one of them. I propose that Boots leadership develop organically as it has in Foresight, and by virtue of it being a Foresight sub-project (or SIG?) that the Foresight council can provide organizational oversight as needed.

Intent

Boots is intended to be constructive participant, a "good citizen", in both the Foresight and Fedora development communities.