On Thu, Oct 7, 2021 at 6:28 AM Neal Gompa <ngompa13(a)gmail.com> wrote:
On Thu, Oct 7, 2021 at 9:24 AM Troy Dawson <tdawson(a)redhat.com>
> On Wed, Oct 6, 2021 at 7:39 PM Neal Gompa <ngompa13(a)gmail.com> wrote:
>> On Wed, Oct 6, 2021 at 3:36 PM Troy Dawson <tdawson(a)redhat.com> 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"
I have an idea of how to do this, so I'm willing to volunteer to write and
>> > 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
>> 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
> Someone correct me if I'm wrong.
> - 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" 
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
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
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
I really want to pull that code together and make "willit"
> - 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