My perhaps ill-considered "Derivation perspective" email regarding
the underlying basis of Foresight development has made two things
clear. The first is that there is real value in from-source
rebuilds of at a minimum large portions of the software stack
(the *whole OS* is the desktop!), and the second is that there is
widespread interest both in Foresight and in a potential stand-alone
import of Fedora, as I suggested.
Furthermore, it has become clear that the interest in a Conary import
of Fedora RPMs as a functioning Conary-based OS is mostly orthogonal
to how much, if any, of Foresight directly consumes those bits. It
would be useful to Foresight even if none of those bits were directly
consumed in Foresight. It has also become clear that there are multiple
upstream sources of OSes that developers would like to see in a Conary
repository.
So, without further ado, I'd like to propose two related high-level
things to the Foresight council:
o Importing other distributions into Conary repositories can be
a Foresight activity where there's any reason it could be
useful in a Foresight context, and that special interest groups
of Foresight devs can formally do such imports in the context
of Foresight. Such imports would have their own JIRA id keys
and so forth.
o Specifically, as an instance of this, importing binary RPMs (and
possibly also separately a source rebuild) of Fedora, creating
a "Fedora Remix" in a Conary repository. Several Foresight
developers have expressed an interest in participating in that
work for various reasons.
Ken's interest in an Ubuntu import made it clear to me that I want
to propose the generic idea of imports as well as the specific one
that I find interesting right now. (Perhaps another contributor
would be interested in importing PCLinuxOS, for example.)
The rest of this mail is about the specific instance of an import
of binary RPMs from Fedora as a Fedora Remix. I have reserved the
repository "boots.rpath.org" for this purpose. For the purposes
of this email, I will call this Fedora Remix "boots", and I also
propose that as the final name of this Fedora Remix.
Potential utility to Foresight:
o Point of comparison: A similar (config files, kernel, toolchain,
etc.) distro packaged with Conary makes it easy to compare both
statically (conary rdiff, for example) and at runtime
(substituting components on a running system) for investigation
of both bugs and features. (For example, a recently-fixed
brasero packaging bug could have been trivially investigated
using conary rdiff between a Boots repository and the Foresight
repository, if Boots had existed.)
o Effective differentiation by reduced dilution of effort: Having
another distro with a (roughly) compatible toolchain and some
low-level libraries means that many one-off package requests
for Foresight could be resolved by simply pointing the requester
to the Boots package, when there is no obvious other reason to
build and maintain the package for Foresight proper.
o Effective focus by reducing pressure for time-based releases:
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.
o Potential source of Foresight binary packages: If for some
packages, core Foresight developers determine that there is
no significant value to Foresight in maintaining that package
as a source build, the Boots packages would be available as a
direct source for Foresight. (Presumably, the -devel group
would reference Boots packages, which would be promoted onto
the Foresight -qa label, just as rbuild does by default when
it runs promotes.)
o Reducing confusion: Doing this as a Foresight project officially
will make the actual intent of the participants clearer -- no
one who has expressed interest in contributing to this effort
wants to damage Foresight; the desire is for augmentation and
specialization.
The next question is: What resources are being offered?
o rPath has open-sourced "mirrorball", an import tool appropriate
for this purpose.
o I personally offer a 750GB SATA hard drive to add to fdev to
increase available space to handle the requirements of the
update process. I will also work on optimizing fdev for
faster building.
o 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.)
o Multiple developers, inside and outside of rPath, have offered
their time to help maintain this import. I am one of them.
I propose that Boots leadership develop organically as it has in
Foresight, and that by virtue of it being a Foresight sub-project
or SIG that the Foresight council can provide organizational
oversight as needed.
Proposed characteristics of Boots:
o As faithful as possible an import, within the constraints of
being a Conary import. At this time, these constraints include:
- Anaconda is (based on?) the rPL or Foresight version, not
the latest Fedora upstream. (Need "appliance installer"
tarball support, as well as Conary 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.)
- Primarily a binary import, with packages modified or rebuilt
from source as necessary to work as a Conary-based distro
(including changing PackageKit to use the Conary backend.
- No SELinux
- Tag scripts, not RPM scripts/triggers
- File conflicts must be resolved to a single owning package with
dependencies included so that packages work.
- Trademark compliance relative to upstream trademark requirements.
- Full import of essentially all RPMs, 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.) In particular, this implies that
RPM itself is fully imported, even though running RPM 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.
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.
o Import will include the updates released as part of Fedora.
o New Fedora releases will be imported on new labels.
o 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.
_______________________________________________
Foresight-devel mailing list
Foresight-devel@lists.rpath.org
http://lists.rpath.org/mailman/listinfo/foresight-devel
