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! > 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. -- 真実はいつも一つ！/ 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
