Re: Planning for EPEL9

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





On Thu, Jul 8, 2021 at 7:51 AM Mohan Boddu <mboddu@xxxxxxxxxx> wrote:
On Thu, Jul 8, 2021 at 9:58 AM Neal Gompa <ngompa13@xxxxxxxxx> wrote:
>
> On Thu, Jul 8, 2021 at 9:39 AM Kevin Fenzi <kevin@xxxxxxxxx> wrote:
> >
> > On Wed, Jul 07, 2021 at 08:32:27PM -0400, Neal Gompa wrote:
> > >
> > > This is very exciting!
> > >
> > > However, question here: At least for the bootstrap for RHEL 9 GA,
> > > couldn't we use the EPEL9 next buildroot to rebuild everything once
> > > instead of rebuilding 5 times? We can then remove the EPEL9 next
> > > buildroot from the EPEL9 buildroot so that state doesn't persist after
> > > everything is done. This also makes it so we can ignore the
> > > "noautobuild" file the one time that all the content needs to be
> > > properly seeded in EPEL9.
> >
> > But at the time of RHEL9.0 GA, cs9 may well have already moved on to
> > 9.1... so that might result in stuff that doesn't work/install/depsolve
> > with 9.0? Or am I missing something there...
> >
>
> Based on what goes on now for EPEL8 and EPEL8 next, I think the
> likelihood of that being a problem is fairly low. Ones where this is a
> problem can be individually handled after the reset, and we'd waste
> far less build resources in doing so.

I still dont understand the advantages of it, we will be running the
mass rebuild after RHEL 9.0 GA, so it wont be saving time (other than
the time needed to setup the epel9 buildroot from rhel9 content). We
will rebuild everything, so it wont be saving any builder/storage
resources.

I still prefer epel9 is built from rhel9 rather than CS after rhel
goes GA as it always has been.

What about, instead of the epel9-next buildroot, we just use the epel9-next repo.  Those packages that have already been built for epel9-next.
That way, we'd get all those dependencies that we built up in epel9-next, without any CentOS Stream 9 packages that might have moved on.

Troy

_______________________________________________
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

[Index of Archives]     [Fedora Announce]     [Fedora News]     [Fedora Cloud]     [Fedora Advisory Board]     [Fedora Education]     [Fedora Security]     [Fedora Scitech]     [Fedora Robotics]     [Fedora Maintainers]     [Fedora Infrastructure]     [Fedora Websites]     [Anaconda Devel]     [Fedora Devel Java]     [Fedora Legacy]     [Fedora Desktop]     [Fedora Fonts]     [ATA RAID]     [Fedora Marketing]     [Fedora Management Tools]     [Fedora Mentors]     [Fedora Package Announce]     [SSH]     [Fedora Package Review]     [Fedora R Devel]     [Fedora PHP Devel]     [Kickstart]     [Fedora Music]     [Fedora Packaging]     [Centos]     [Fedora SELinux]     [Fedora Legal]     [Fedora Kernel]     [Fedora QA]     [Fedora Triage]     [Fedora OCaml]     [Coolkey]     [Virtualization Tools]     [ET Management Tools]     [Yum Users]     [Tux]     [Yosemite News]     [Linux Apps]     [Gnome Users]     [KDE Users]     [Fedora Tools]     [Fedora Art]     [Fedora Docs]     [Maemo Users]     [Asterisk PBX]     [Fedora Sparc]     [Fedora Universal Network Connector]     [Fedora ARM]

  Powered by Linux