Going back to the questions. See comments inline. On Tue, Mar 24, 2020 at 3:17 PM Miro Hrončok <mhroncok@xxxxxxxxxx> wrote: > > 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. 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. > > 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. But also by contributing directly to ELN compose configuration. > > 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. For that we need rpm conditionals based on disttag. 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. > > 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. Let's discuss it in the ticket then? > > * 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/ > > > ** 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. > > == 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". This is tracked in the FPC ticket. > 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? 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. 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. > 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. > > == 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. > ----------- > > 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? There are options here, as it depends on the rate of sidetag builds and the size of them. 1) we can do only a post-merge rebuild Rebuild packages in the same order directly into the ELN buildroot 2) we can do a proper sidetag gating event, which means as soon as sidetag is announced as ready to be tested, we take the list of packages from it and rebuild it in the same order with ELN buildroot enabled (via mock probably). I think we will start with 1) even though it will most likely fail in the process, and require manual work, and then add 2) to make it cleaner. > 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? This is mentioned in the Change: we are going to use Rawhide Gating to provide feedback on such failures. Maintainer of the package will decide if the update will be blocked on that or not. ELN SIG and downstream developers will be alerted of such failures and try to come up with solution for them as well. > 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. > 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? Going to come back to this in another mail. > -- > 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 -- Aleksandra Fedorova bookwar _______________________________________________ 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
