V Thu, Jul 08, 2021 at 05:24:05AM -0400, Neal Gompa napsal(a):
On Thu, Jul 8, 2021 at 5:19 AM Petr Pisar <ppisar(a)redhat.com>
wrote:
>
> V Thu, Jul 08, 2021 at 04:47:33AM -0400, Neal Gompa napsal(a):
> > On Thu, Jul 8, 2021 at 4:41 AM Miro Hrončok <mhroncok(a)redhat.com> wrote:
> > >
> > > On 08. 07. 21 2:28, Mohan Boddu wrote:
> > > > Also, people who wish to opt out of this mass rebuild can add
> > > > 'noautobuild' file to the epel9-next branch beforehand, this
however
> > > > does not stop from creating the epel9 branch, just the package
won't
> > > > be included in the rebuild.
> > >
> > > I think there are 3 possible opt outs here:
> > >
> > > 1) The epel9-next packager does not intent to maintain the package in
epel9,
> > > only in epel9-next. While we might not like this goes, as long as there is
no
> > > policy against this approach, always creating the branch will create work
for
> > > the packager they have not signed for. I think there should be an opt out
for
> > > branching as well.
> > >
> >
> > This is not a valid use-case.
>
> Why?
>
> If you were a CentOS user who moved to CentOS Stream, then you are going to
> use epel9.next. You have no use of epel9.
>
That is not the point of epel-next. It's only intended to be a overlay
for resolving issues between RHEL minor releases (or in this case,
bootstrapping before RHEL major releases are actually out).
EPEL-next is usually layered on top of EPEL, not the other way around.
I'm proposing we layer EPEL on EPEL-next just long enough to do a mass
rebuild cycle to populate EPEL9, then revert to the normal setup.
I see. So if you are a CentOS Stream user, you need use both epel9 and
epel9-next.
In that case the EPEL 8 Next annoucement
<
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproj...
was quite misleading. Especially without reading the linked Wiki page.
DNF should acquire dependencies among repositories. I saw so many EPEL bug
reports explained by missing powertools repository. The history will repeat.
-- Petr