On Thu, Oct 7, 2021 at 9:44 AM Troy Dawson <tdawson(a)redhat.com> wrote:
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> wrote:
> >
> >
> >
> > 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"
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...
[2]:
https://gitlab.com/redhat/centos-stream/release-engineering/comps/-/merge...
[3]:
https://gitlab.com/redhat/centos-stream/release-engineering/comps/-/merge...
--
真実はいつも一つ!/ Always, there's only one truth!