Re: Planning for EPEL9

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

 



V Wed, Jul 07, 2021 at 08:32:27PM -0400, Neal Gompa napsal(a):
> On Wed, Jul 7, 2021 at 8:28 PM Mohan Boddu <mboddu@xxxxxxxxxx> wrote:
> > While we are already working on epel9-next enablement, there was a
> > discussion about how to handle epel9 when rhel9 goes GA. It is safe to
> > assume that a lot of the builds that are already in epel9-next at that
> > point of time should work on rhel9.
[...]
> > Couple of questions that need to be answered here:
> > 1. Is 5 times of rebuilds good enough or do we need more?
> > 2. Do the mass rebuild builds have to go through bodhi or can we just
> > directly tag them for stable compose?
> >
> > Any suggestions appreciated.
> >
> 
> 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?

That would be indeed helpful when dealing with build cycles. Because whatever
times you attempt to rebuild them without changing their spec files (or spec
macros), you won't succeed.

On the other hand it arises a problem with disappearing (build-)required
packages whose maintainer requested noautobuild after uninheriting epel9-next
builds. (E.g. you would get epel9 packages that you cannot build again.)
But that should not be a big problem because mismatches between those two
requiring and required packages would appear even in the original approach.
Only later. And naturally, maintainers would have to cooperate and agree
wheter to keep or remove both of the packages.

Maybe one could do the mass rebuild twice. The second one without epel9.next
builds to verify that epel9 is self-contained. The scratch rebuilds would do
either.

-- Petr

Attachment: signature.asc
Description: PGP signature

_______________________________________________
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