Many of us deeply involved in RHEL's production are excited about this
idea. We are looking for ways to do more of the RHEL 9 creation
activities in public and this could help serve that purpose.
Something along these lines would be fantastic because identical
Fedora sources could be used to produce differentiated builds, where
only inherited rpm macros would differ. Perhaps even better is that
it looks like it would give Fedora the ability to do more to serve its
own mission, by allowing customization without forking sources.
Fedora would be able to grow beyond the traditional
On Mon, Jan 13, 2020 at 8:45 AM Aleksandra Fedorova
This topic goes along the lines of Matthew’s Operating System Factory
discussion, but with a slightly different angle. It also is the
generalization of the Change we have proposed recently 
So let me start with the problem:
In Fedora now we have a well known and established process of how to
deal with updates that bring new content through packages. There are
ways to package new content side by side with the old one, to perform
a non-disruptive testing, iterate and upgrade.
What I think is missing is the way to safely iterate on the process,
which happens after the content is packaged. Examples are: changes to
buildroot configuration as in , changes in comps files, for example
required for Minimization Objective , changes in compose building
process, changes in Mass Rebuild and so on.
For such changes we have to use an all-or-nothing approach, which
means we either implement the change too early or postpone it for too
To add flexibility to the Fedora process, I’d like to propose the
concept of alternative buildroots.
Note: The naming is hard here, and while I tend to call it
“buildroot”, it actually needs to be called “alternative everything,
except the srpms”.
I think we shouldn’t use the word “variant”, “spin”, “flavour” or
something like that to describe it, as it is strictly the shared
development playground linked to the latest Fedora Rawhide state and
focused on the build and compose process. It is definitely not the
alternative Fedora. It shouldn’t have releases on its own, it has no
branches in the source code and it doesn’t target end-users.
The good thing is that, with the distributed CI approach we have
implemented, we are ready to consume the feedback from such
alternative setups in a non-blocking but informative way. I think we
can extend our use of CI machinery so that it simplifies the
development process for everyone, removing redundant heads-ups but
increasing the targeted collaboration in places where it is actually
### Use cases ###
The first example of such a buildroot is provided by the CPU baseline
There will be more, since we may want to work on comps files for
There is also one particularly important case of the RHEL bootstrap:
RHEL tries hard to inherit as much as possible from Fedora, but since
both Fedora and RHEL have historically different build and compose
configurations, it is often problematic to deal with dependency and
build issues which arise from it. To the point that RHEL sometimes
just can’t use Fedora as an origin, and needs to find its way around.
The alternative buildroot targeting CentOS and RHEL would provide an
open shared development environment. There we can work on converging
the RHEL process to Fedora, and also on improving Fedora process with
things, which RHEL and CentOS have discovered.
### Proposal ###
This idea doesn’t quite fit into the Fedora Changes framework, as
there is no actual change to Fedora. And we don't even have a concept
of an Infrastructure Change at this point.
But there are several items one can think about:
1) Though as I said above the “buildroot” term is slightly misleading
but it is a start. And the change  is a first step, the prototype,
which goes into that direction. Its main focus is the compiler
parameters rather than anything else.
2) The second part of the proposal is to setup a CentOS/RHEL-targeting
buildroot and compose, with a focus on comps, dependency chains and
compose differences. Which I think overlaps in a certain way with the
3) And the third part is to generally develop the alternative
buildroot as a concept. It should be our toolbox item, something
similar to the alternative architectures approach. So that it can be
requested by anyone based on the existence of a SIG or working group,
which would own and maintain it.
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines