On 25. 03. 20 12:49, Aleksandra Fedorova wrote:
Going back to the questions. See comments inline.
Thanks.
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.
It says that we are going to continuously build el-like compose. We
are adding new pieces of infrastructure to make that happen.
This is an infrastructure change, which doesn't change Fedora content.
It will eventually change Fedora sources. But even with "this doesn't change
anything" argument, I find the current summary confusing a bit without reading
the rest of the proposal. Can a second sentence like "A new buildroot will be
added Koji that will automatically build packages from master but it have a
different set of macros and config." be added?
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.
By contributing to Fedora Rawhide sources and consuming them as ELN
repositories for testing purposes.
The change proposal literally says "There is no user-facing part in this change.
No ELN artifacts are going to be shipped to the end-user."
As a contributor, how do I consume the content if I cannot consume the content?
As I understand it, the "end-user" and "user-facing" terms must have different
meanings in this context, right? What is this meaning?
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?
As a nitpick, it doesn't say _new_ conditionals there. As we don't
want to branch Fedora Rawhide we need a possibility for certain
package to be built differently in the ELN environment.
The ticket says the "new" conditionals (with %{eln}) will be discouraged.
Hence the means to achieve the goal will be the "old" conditionals (with
%{rhel}/%{fedora}). Correct?
For that we need rpm conditionals based on disttag.
This might be a terminology dispute and bike shedding, but I still don't
understand what does "conditionals based on disttag" means. I've asked for an
example in the FPC ticket and apparently the conditionals are not to be based on
disttag. I think a very thorough decision should be maade regarding the
conditionals and dist tag:
- should %{fedora} be defined at all?
- should %{eln} be versioned?
- should the dist tag be versioned? (see Neal's point with the Koji nevr check)
We can surely do it in the FPC ticket, but people are not gonna find that
discussion there.
This is a chicken and egg problem, to be honest. To figure out the
details we need FPC and others contribution, but then to start talking
to FPC we need a Change Proposal so that you get the idea what are we
trying to achieve and why.
As a member of the FPC I don't think you need to involve FPC at all at this
point other than getting feedback. And I don't see a chicken and egg problem in
here - you have the proposal and we are discussing it.
... Some unknown number of packages that rely on `if !
0%{?fedora}` will require manual intervention.
And many other cases, see the FPC ticket.
Let's discuss it in the ticket then?
I'd rather discuss this here and only come to FPC for approval of new guidelines
when ready. The FPC members who are likely to discuss this are already
discussing this here. Why spitting the discussion into two places?
However, if you prefer to discuss this in the FPC ticket, sure. There is plenty
of feedback now (from people who I assume have come because they have read my
e-mail with the link, but maybe they were just subscribed to the FPC
tickets...). FESCo and FPC tickets are IMHO not a good place to discuss ideas
like this:
- there are no threads
- people there are not "equal" (one group is in the position of power)
- people usually don't follow new tickets
* 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.
I am not sure what kind of details you expect.
Will it help if I add a link to CentOS compose? Like this one
http://mirror.centos.org/centos/8.1.1911/
Partially, yes. Bot mostly: Who decides how is this new repo split into multiple
repos - is it a Fedora (aka FESCo) level decision, or does releng maintain this,
or is it part of the ELN configuration maintained by the change owners? Can
Fedora contributors contribute to this, or is it an internal RH decision?
** 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?
For third-parties who develop services and tools for CentOS and RHEL
it is important to have development environment which is close to what
they will achieve in the released version.
Fedora Rawhide is the future RHEL, but as it is packed differently it
is harder to rely on it, when you plan the future of your third-party
service.
ELN compose is a preview of what may happen if we take current Fedora
Rawhide and try to make CentOS/RHEL out of it, like right now. It is a
preview of issues we are going to have as well.
Let's not repeat Neal here:
https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx/message/MQVV4AAXLLYJCU5AHPOP5MJOEUVKZCT2/
"Nothing has ever stopped any project from using Fedora..."
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?
Do you have specific example or asking generally?
There are some examples elsewhere in this thread. But I am asking generally.
I think that not having eln-branch is very important part of the
concept as we don't want to fork Fedora. By using conditionals in spec
files we do create variants of the rpm, but at list we get them
automatically synced with the upstream sources. So whenever you update
the package in Rawhide, ELN binary package is updated too.
Conditionals create problems indeed, we should use them carefully. I
would prefer if instead of conditionals we find ways how to make
Fedora packages more flexible, change from Requires to Suggests for
example, or split into subpackages.
But in this case I think conditionals are a much better choice than
branching, as when done once, they require less maintenance on their
way to downstream.
Sure They are good for downstream. RHEL clearly benefits from this.
But they impose additional cognitive overhead on the community maintainers in
Fedora.
We add conditional in Rawhide, we inherit it in branched Fedora, we
consume it in CentOS Stream, we get it in EPEL. All of it happens
automatically once we have the ELN compatibility in Rawhide.
This is all nice only as long as you prefer conditionals over branching. For a
Fedora maintainer who doesn't, this is just "unnecessary cruft" in the spec file.
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?
We don't have power to enforce anything, and we don't want it.
We'd like to find such problematic places and start a conversation for
them. See if we can negotiate a better solution: split into
subpackages, maybe use modules even. There is no one good answer which
fits for all, it needs to be resolved on a case by case basis.
Yes, there is a risk that it won't work. And we have a very clean
contingency plan for it: we shutdown the whole thing.
It will be unfortunate, but it is an option.
What is to stop us saying "stop acting like we can stop doing this now and start
over at this point" when we realize this is hurting the Fedora community, but we
need to ship next RHEL? (Sspeaking from experience. Things like this were said.)
== 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?
It is described in "How to Test" section.
Those sections contradict each other in that case.
Will there be a way to opt-out packages (or stacks of them) from ELN if they are
not interesting for RHEL?
We want to start with a subset of packages at the beginning (basic
buildroot packages, system-level packages and so on) and see if it can
grow beyond EL-subset later.
I think we should cover EPEL packages too, so it already goes further
than just RHEL.
So this is already the plan (only have some packages)? I have not understood
that from the proposal at all.
--
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
