On Thu, Oct 7, 2021 at 9:44 AM Troy Dawson <tdawson@xxxxxxxxxx> wrote: > > > > On Thu, Oct 7, 2021 at 6:28 AM Neal Gompa <ngompa13@xxxxxxxxx> wrote: >> >> On Thu, Oct 7, 2021 at 9:24 AM Troy Dawson <tdawson@xxxxxxxxxx> wrote: >> > >> > >> > >> > On Wed, Oct 6, 2021 at 7:39 PM Neal Gompa <ngompa13@xxxxxxxxx> wrote: >> >> >> >> On Wed, Oct 6, 2021 at 3:36 PM Troy Dawson <tdawson@xxxxxxxxxx> wrote: >> >> > >> >> > *this is worth a discussion in todays EPEL Steering Committee Meeting* >> >> > >> >> > It sounds like the epel9-next is going to startup by building against the CS buildroot. Changing it at this time would cause a delay. >> >> > >> >> > Thus we need to write some "verify build deps are released" checker. I have an idea of how to do this, so I'm willing to volunteer to write and run something. >> >> > >> >> > But, it would be good to have some discussion to determine if we want to keep using the CS buildroot for epel9-next, always. Or if we want to use it just as a bootstrap mechanism, and then switch to building just off the available CentOS Stream repos at some point. >> >> > >> >> > Thoughts? >> >> > Should we always use buildroot? Or just keep up until we're fairly stable? >> >> > >> >> >> >> We should only use the buildroot repo for as long as we need to. The >> >> *sooner* we can switch to the published content, the better. >> > >> > >> > This was discussed at the EPEL Steering Committee meeting. Here is the summary. >> > Someone correct me if I'm wrong. >> > >> > epel9-next: >> > - starts off building off CS buildroot >> > - I will write a "check if all build packages are in the normal repos" checker, called "will it build" [1] >> > >> >> How are we going to know whether all the build-time and run-time >> packages are in the normal repos? We need to check generated >> dependencies too, especially now that it's possible to have dynamic >> BuildRequires! > > > run-time dependencies: > That's always been a problem, even without the buildroot. > But I will also be writing a "will it install" to go along with "will it build" > > build-time dependencies: > Grab the root.log of the package build, and parse it. > This gets around any hidden and dynamic BuildRequires. > I've already written code that does this for Content Resolver, and checked it against traditional dnf/libsolve dependency generation. > It was 98% equal, and those 2% were on packages where it was possible for more than one package to be installed for a dependency, and for that, I'd prefer going with the root.log. > > I think I've got everything I need already written, just in three separate projects. > I really want to pull that code together and make "willit" > >> >> > epel9: >> > - Use normal RHEL 9 repos (AppStream, BaseOS, CRB) >> > >> > Checks/Tests/Future: (It's a little fuzzy on the timing of these) >> > >> > - grobisplitter >> > -- see if we really need to use grobisplitter >> > -- I'm a little fuzzy on how or when we are going to test this >> > >> >> With the retirement of the container-tools default module, >> grobisplitter will not be required at all unless we want to use it to >> support non-default modules. > > > That is the theory, yes, that grobisplitter isn't required. > But nobody was able to say that was for certain. Thus, it needs to be tested. > I've verified this with my internal build infrastructure, so yes, I know it's not required. Admittedly, it's not a Koji system, but I'm also not enabling any modules in my build environment right now. I'm rebuilding content from Rawhide targeting CentOS Stream 9 to get a list of initial EPEL 9 packages to build for work, which is how some of my requests to add stuff to CRB have come about[1][2][3]. This can also be verified when using something like mock with mock-core-configs v36 or higher, because I made the necessary adjustments to test building on CentOS Stream 9 the same way that Fedora Koji and the CentOS CBS would. [1]: https://gitlab.com/redhat/centos-stream/release-engineering/comps/-/merge_requests/140 [2]: https://gitlab.com/redhat/centos-stream/release-engineering/comps/-/merge_requests/139 [3]: https://gitlab.com/redhat/centos-stream/release-engineering/comps/-/merge_requests/135 -- 真実はいつも一つ！/ Always, there's only one truth! _______________________________________________ epel-devel mailing list -- epel-devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to epel-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/epel-devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
