On Thu, Oct 7, 2021 at 9:24 AM Troy Dawson <tdawson@redhat.com> wrote:
>
>
>
> On Wed, Oct 6, 2021 at 7:39 PM Neal Gompa <ngompa13@gmail.com> wrote:
>>
>> On Wed, Oct 6, 2021 at 3:36 PM Troy Dawson <tdawson@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" 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.
Troy