On 24. 03. 20 10:32, Aleksandra Fedorova wrote:
As Ben is on PTO, I'd like to present the System-Wide Change
https://fedoraproject.org/wiki/Changes/ELN_Buildroot_and_Compose
== Summary ==
The goal of the ELN project is to continuously build Fedora Rawhide
packages and composes in the way which resembles the CentOS and RHEL
build process and to provide a feedback loop for Fedora maintainers on
the status of those builds.
Form a Fedora POV, this doesn't state what's being "changed" at all.
I would appreciate if it actually said something about the ELN Buildroot and
Compose.
ELN is an evolution of the request for an alternate buildroot for
newer x86_64 processors. The reasoning behind that new buildroot was
that we expected that the next major release of RHEL would likely drop
support for older hardware and therefore could take advantage of
enhancements and processor extensions available for newer hardware. As
plans for this proceeded, they expanded into a desire to do more than
just test out the processor architecture. Instead, we want to have a
complete alternative compose of Fedora Rawhide that resembles the way
that Red Hat and CentOS builds their packages. The idea being that
Fedora developers and third-party vendors who rely on Red Hat
Enterprise Linux have a place where they can directly contribute to
what will eventually become the next RHEL.
I don't understand from the rest of the change how do they contribute to ELN.
ELN (Enterprise Linux Next) is going to be that place. What we want to
do is establish a set of RPM conditionals that can be used for the set
of packages that may need to be built differently for a RHEL-like
target as compared to a Fedora one. (For example, we may want to skip
regenerating documentation during package-build and instead use
pre-built docs from the tarball or SRPM.)
What set of RPM conditionals? This is more clear from the FPC ticket:
https://pagure.io/packaging-committee/issue/955
But even there, it seem that any new conditionals will be discouraged, so what
are the new conditionals this change is talking about?
This includes:
* buildroot configuration, rpm macro and compile flags,
* comps files and the compose content,
* compose itself and the pipeline which builds it.
Where are those rpm macros and compile flags be defined if this builds from
master? Will there be an alternative branch for (and only for)
redhat-rpm-config, or will redhat-rpm-config be full of such new conditionals?
Are the maintainers of redhat-rpm-config on board?
... Some unknown number of packages that rely on `if !
0%{?fedora}` will require manual intervention.
And many other cases, see the FPC ticket.
* CentOS Stream, EPEL and RHEL
** We are going to build Fedora packages into a compose similar to the
multi-repo structure of CentOS and RHEL.
This lacks any details in the description.
** The feedback pipelines built for the project will allow downstream
developers to open up their work and bring it closer to Fedora. In
particular, it will enable projects like OpenShift to do their work in
Fedora.
I don't understand how. Do you have more details?
== Scope ==
* Proposal owners:
** Setup build environment for a new disttag (`eln`).
** Setup automation to trigger new ELN build every time there is a new
update submitted to Fedora Rawhide.
** Post build result to Fedora Messaging, so that it appears in Bodhi
and can be used as a
[https://docs.fedoraproject.org/en-US/rawhide-gating/ gating test].
** Setup automation to run periodic partial composes (via ODCS)
without installation media to generate repositories with these
packages.
** Update packaging documentation to mention new disttag and how it can be used.
* Other developers:
*: Anyone who wants to produce different content for the ELN compose
will need to implement the new macros in their specfile. The
overwhelming majority of packages will require no modification.
I don't understand the meaning of "implement the new macros". Do I read it that
if I want to produce different content for the ELN compose, I need to use %if
conditionals for %{rhel}? What if I don't want such conditionals, because I
prefer to have separate branches?
I also don't understand how this will work if only the packager who want this
will participate. Assume you need to build your package "like in the next RHEL",
so you adapt it (let's say you disable the "shakehands" feature, because you
don't plan to include "libshakehands" in future RHEL). As a consequence,
packages depending on your package and might also need adapting (becasue they
assume the shakehands feature is available by default). What if the maintainer
of a dependnign package doesn't like %{rhel} conditionals in their specs? Will
the changes be forced? Or will parts of the ELN compose fail to build or install
forever because of this?
== User Experience ==
There is no user-facing part in this change. No ELN artifacts are
going to be shipped to the end-user.
As a packager debugging a problem in ELN, how do I consume it?
-----------
General questions/feedback follows:
The description of this change is very vague. I don't know if it is intended or
not, but it is very unclear to me, how will this new buildroot work. For example:
Will there be any inheritance from rawhide? After the FESCo meeting I assume
yes, but would like a record of this on the mailing list.
How do we bootstrap things in ELN without disturbing regular rawhide? For
example, assume the following situation:
There is libchicken-1 and libegg-1 in rawhide as well as ELN. They require and
buildrequire each other. The maintainer needs to do an update. He does the
following in Fedora:
- request a side tag
- builds libchicken-2 with bundled egg-2
- builds egg-2
- rebuilds libchicken-2 against the egg-2 package
- request a side tag merge
What happens in ELN? Will all side tags automatically create a bound ELN side
tag? Or after the side tag is merged, libchicken and libegg will be untagged
form ELN and rebuild against the rawhide versions?
What happens upon ELN build failures? Assume the omelette package fails to build
in ELN because the chicken and egg problem. Who will chase this and how? Will
the omelette maintainer receive an automatic bug report to fix their package or
will an ELN developer fix this for them? Where do they commit their fixes, if
everything builds from master?
Will there be a way to opt-out packages (or stacks of them) from ELN if they are
not interesting for RHEL?
I could go on with further scenarios and what-ifs. I undrstand if the answer is
"we don't know yet". But the Change proposal should at least try to explain how
this buildroot works.
An extra question: How does this play with modularity, if at all. Do we also
rebuild all modules?
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
