EPEL 10.0 mass branching

[Carl George]

Hello EPEL packagers,

Later today (2025-02-18), Release Engineering will branch epel10.0
from epel10, in accordance with our overall branching strategy for
EPEL 10.

https://docs.fedoraproject.org/en-US/epel/branches/#_epel_10

During the branching, we will temporarily disable builds to the
epel10-candidate target, which is used when you run `fedpkg build`
from the epel10 branch.  If you are trying to create a build and
receive an error about a target not existing, please try again later
in the day.  Because this is the first time we are doing an EPEL mass
branching, we don't know precisely how long it will take or how long
we will need to disable the builds for.

Thanks in advance for your patience.

EPEL-ANNOUNCEEPEL 10.0 mass branching

[Carl George]

On Tue, Feb 18, 2025 at 2:16 AM Carl George via epel-announce
 wrote:
> Hello EPEL packagers,
>
> Later today (2025-02-18), Release Engineering will branch epel10.0
> from epel10, in accordance with our overall branching strategy for
> EPEL 10.
>
> https://docs.fedoraproject.org/en-US/epel/branches/#_epel_10
>
> During the branching, we will temporarily disable builds to the
> epel10-candidate target, which is used when you run `fedpkg build`
> from the epel10 branch.  If you are trying to create a build and
> receive an error about a target not existing, please try again later
> in the day.  Because this is the first time we are doing an EPEL mass
> branching, we don't know precisely how long it will take or how long
> we will need to disable the builds for.
>
> Thanks in advance for your patience.
>
> --
> Carl George
>
> --
> _______________________________________________
> epel-announce mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> 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/[e-mail]...
> Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue

We have completed mass branching for epel10.0.

The epel10-candidate target has been restored, and you can resume
building from the epel10 branch.  Doing so will result in builds for
EPEL 10.1.  EPEL 10.0 builds that were submitted before the branching
point are being tracked and will get tagged into epel10.1 once they
reach stable status and get the epel10.0 tag.

If you still want to build specifically for EPEL 10.0, you can build
from the epel10.0 branch.  If you request an epel10 branch for a
package after this point, the epel10.0 branch will not be created
automatically and must be requested separately.  Please note that a
bug in fedpkg was discovered today and that a request for an epel10.0
branch will also result in invalid requests for a corresponding repo
and branch in the modules namespace.  These can be closed as invalid,
while the epel10.0 branch request in the rpms namespace should process
correctly.  We hope to get this fixed in fedpkg soon.

Thanks for your patience and happy packaging!

EPEL-ANNOUNCERe: EPEL 10.0 mass branching

[Fabio Valentini]

On Wed, Feb 19, 2025 at 5:50 AM Carl George via epel-announce
 wrote:
> If you still want to build specifically for EPEL 10.0, you can build
> from the epel10.0 branch.  If you request an epel10 branch for a
> package after this point, the epel10.0 branch will not be created
> automatically and must be requested separately.  Please note that a
> bug in fedpkg was discovered today and that a request for an epel10.0
> branch will also result in invalid requests for a corresponding repo
> and branch in the modules namespace.  These can be closed as invalid,
> while the epel10.0 branch request in the rpms namespace should process
> correctly.  We hope to get this fixed in fedpkg soon.

As a temporary workaround until this is fixed in fedpkg, you can add
the `--no-auto-module` flag when running `fedpkg request-branch
epel10.0`, which prevents creation of the two unwanted / wrong
tickets.

Fabio

EPEL-ANNOUNCEEPEL 10.0 mass branching

[Remi Collet]

Le 18/02/2025 à 09:13, Carl George via epel-announce a écrit :
> Hello EPEL packagers,
>
> Later today (2025-02-18), Release Engineering will branch epel10.0
> from epel10, in accordance with our overall branching strategy for
> EPEL 10.
>
> https://docs.fedoraproject.org/en-US/epel/branches/#_epel_10

Can you please confirm if 10.0 new builds will be available
in "10" (for CentOS Stream users) ?

Or do I have to build in both branches ?

Remi

EPEL-ANNOUNCEEPEL 10.0 mass branching

[Troy Dawson]

On Thu, Feb 20, 2025 at 12:10 AM Remi Collet 
wrote:
> Le 18/02/2025 à 09:13, Carl George via epel-announce a écrit :
> > Hello EPEL packagers,
> >
> > Later today (2025-02-18), Release Engineering will branch epel10.0
> > from epel10, in accordance with our overall branching strategy for
> > EPEL 10.
> >
> > https://docs.fedoraproject.org/en-US/epel/branches/#_epel_10
>
> Can you please confirm if 10.0 new builds will be available
> in "10" (for CentOS Stream users) ?
>
> Or do I have to build in both branches ?

Currently there are two branches.
epel10
epel10.0

Everything built in epel10 will have a dist-tag of epel10_1 and will go
into the epel10 repo.  This is consumed by CentOS Stream 10.

Everything build in epel10.0 will have a dist-tag of epel10_0 and will go
into the epel10.0 repo.  This will be consumed by RHEL 10.0 only, not
CentOS Stream.

So it depends on what you want.
If you care only about CentOS Stream 10, then just epel10 is needed.
If you want it to be in both RHEL 10.0+ and CentOS Stream 10, then yes, you
have to build it in both branches.

Do not build it in epel10.0 only.  The build will not transfer over.

Troy
p.s. If you are a Fedora package maintainer, picture this being right after
the branching point from rawhide.

EPEL-ANNOUNCEEPEL 10.0 mass branching

[Remi Collet]

Le 20/02/2025 à 15:15, Troy Dawson a écrit :
> On Thu, Feb 20, 2025 at 12:10 AM Remi Collet <[e-mail] 
> > wrote:
> Le 18/02/2025 à 09:13, Carl George via epel-announce a écrit :
>  > Hello EPEL packagers,
>  >
>  > Later today (2025-02-18), Release Engineering will branch epel10.0
>  > from epel10, in accordance with our overall branching strategy for
>  > EPEL 10.
>  >
>  > https://docs.fedoraproject.org/en-US/epel/branches/#_epel_10
> <https://docs.fedoraproject.org/en-US/epel/branches/#_epel_10>
>
> Can you please confirm if 10.0 new builds will be available
> in "10" (for CentOS Stream users) ?
>
> Or do I have to build in both branches ?
>
>
> Currently there are two branches.
> epel10
> epel10.0
>
> Everything built in epel10 will have a dist-tag of epel10_1 and will go 
> into the epel10 repo.  This is consumed by CentOS Stream 10.
>
> Everything build in epel10.0 will have a dist-tag of epel10_0 and will 
> go into the epel10.0 repo.  This will be consumed by RHEL 10.0 only, not 
> CentOS Stream.
>
> So it depends on what you want.
> If you care only about CentOS Stream 10, then just epel10 is needed.
> If you want it to be in both RHEL 10.0+ and CentOS Stream 10, then yes, 
> you have to build it in both branches.
>
> Do not build it in epel10.0 only.  The build will not transfer over.

This is sad and makes double work :(
I really think 10.1 should inherit builds from 10.0

For context, see https://bugzilla.redhat.com/show_bug.cgi?id=2328883

This request for waf in EPEL-10 was only build for 10.1
so not solving original request

IMHO, such problem will be very common, as design is confusing

Remi

P.S. I'm also curious to see how this will be used by RHEL users,
AFAIK using $releasever_major${releasever_minor:+.$releasever_minor}
won't work (minor usually not set)
> Troy
> p.s. If you are a Fedora package maintainer, picture this being right 
> after the branching point from rawhide.

EPEL-ANNOUNCEEPEL 10.0 mass branching

[Petr Pisar]

V Thu, Feb 20, 2025 at 04:24:50PM +0100, Remi Collet napsal(a):
> Le 20/02/2025 à 15:15, Troy Dawson a écrit :
> > Do not build it in epel10.0 only.  The build will not transfer over.
>
> This is sad and makes double work :(
> I really think 10.1 should inherit builds from 10.0
>
> For context, see https://bugzilla.redhat.com/show_bug.cgi?id=2328883
>
> This request for waf in EPEL-10 was only build for 10.1
> so not solving original request
>
> IMHO, such problem will be very common, as design is confusing

The design is confusing for CentOS users, but I hope understandible for RHEL
users. If EPEL wants to cater RHEL where some packages change ABI between
minor releases, there is no way than nursing multiple EPEL builds.

-- Petr

EPEL-ANNOUNCEEPEL 10.0 mass branching

[Remi Collet]

Le 20/02/2025 à 16:38, Petr Pisar a écrit :
> V Thu, Feb 20, 2025 at 04:24:50PM +0100, Remi Collet napsal(a):
> > Le 20/02/2025 à 15:15, Troy Dawson a écrit :
> > > Do not build it in epel10.0 only.  The build will not transfer over.
> >
> > This is sad and makes double work :(
> > I really think 10.1 should inherit builds from 10.0
> >
> > For context, see https://bugzilla.redhat.com/show_bug.cgi?id=2328883
> >
> > This request for waf in EPEL-10 was only build for 10.1
> > so not solving original request
> >
> > IMHO, such problem will be very common, as design is confusing
>
> The design is confusing for CentOS users, but I hope understandible for RHEL
> users. If EPEL wants to cater RHEL where some packages change ABI between
> minor releases, there is no way than nursing multiple EPEL builds.

I'd like to understand by which magic RHEL and Clones
will use the 10.0 repository ?

AFAIK, $releasever is 10 by default.

Remi
> -- Petr

EPEL-ANNOUNCEEPEL 10.0 mass branching

[Alex Iribarren]

Hi,

On 2/21/25 7:20 AM, Remi Collet wrote:
> I'd like to understand by which magic RHEL and Clones
> will use the 10.0 repository ?
>
> AFAIK, $releasever is 10 by default.

DNF now also supports $releasever_major and $releasever_minor.

https://dnf.readthedocs.io/en/latest/conf_ref.html#repo-variables-label

Cheers,
Alex

EPEL-ANNOUNCEEPEL 10.0 mass branching

[Remi Collet]

Le 21/02/2025 à 07:20, Remi Collet a écrit :
> AFAIK, $releasever is 10 by default.

Confirmed on both RHEL-10.0-Beta and AlmaLinux-10.0-Beta

https://forums.almalinux.org/t/bug-epel-repo-missing-releasever-major-and-re...

Sorry, but I think EPEL-10 is broken by design

Remi
> Remi
> > -- Petr

EPEL-ANNOUNCEEPEL 10.0 mass branching

[Sérgio Basto]

On Wed, 2025-03-05 at 13:47 +0100, Remi Collet wrote:
> Le 21/02/2025 à 07:20, Remi Collet a écrit :
> > AFAIK, $releasever is 10 by default.

I maybe I'm seeing this wrong , but $releasever is 10 and repo will
have packages distag 10_1 , or $releasever is 10.0 and packages in the
repo will have distag 10_0 only

no need $releasever_major and $releasever_minor values
> Confirmed on both RHEL-10.0-Beta and AlmaLinux-10.0-Beta
>
> https://forums.almalinux.org/t/bug-epel-repo-missing-releasever-major-and-re...
>
> Sorry, but I think EPEL-10 is broken by design

EPEL-ANNOUNCEEPEL 10.0 mass branching

[Remi Collet]

Le 05/03/2025 à 14:58, Sérgio Basto via epel-devel a écrit :
> On Wed, 2025-03-05 at 13:47 +0100, Remi Collet wrote:
> > Le 21/02/2025 à 07:20, Remi Collet a écrit :
> > > AFAIK, $releasever is 10 by default.
>
> I maybe I'm seeing this wrong , but $releasever is 10 and repo will
> have packages distag 10_1 , or $releasever is 10.0 and packages in the
> repo will have distag 10_0 only

Don't understand this sentence....

To be clear (or try to)

By default (CentOS Stream, RHEL, Alma....)

*    releaserver set to 10
*    releaserver_major set to 10
*    releaserver_minor not set

So will pull from "10" repository (which is really "10.1" for EPEL)

If forced to 10.0

*    releaserver set to 10.0
*    releaserver_major set to 10
*    releaserver_minor set to 0

Then will pull from "10.0" repository (until forced to another value)
> no need $releasever_major and $releasever_minor values

epel.repo uses

metalink=https://mirrors.fedoraproject.org/metalink?repo=epel-$releasever_major$%7Bre...

$releasever_major${releasever_minor:+.$releasever_minor} which is
exactly the same than $releasever (so not useful and less legible)

But $releasever_major can be useful, ex

gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL-$releasever_major

Remi
> > Confirmed on both RHEL-10.0-Beta and AlmaLinux-10.0-Beta
> >
> > https://forums.almalinux.org/t/bug-epel-repo-missing-releasever-major-and-re...
> >
> > Sorry, but I think EPEL-10 is broken by design

EPEL-ANNOUNCEEPEL 10.0 mass branching

[Sérgio Basto]

On Wed, 2025-03-05 at 16:28 +0100, Remi Collet wrote:
> Le 05/03/2025 à 14:58, Sérgio Basto via epel-devel a écrit :
> > On Wed, 2025-03-05 at 13:47 +0100, Remi Collet wrote:
> > > Le 21/02/2025 à 07:20, Remi Collet a écrit :
> > > > AFAIK, $releasever is 10 by default.
> >
> > I maybe I'm seeing this wrong , but $releasever is 10 and repo will
> > have packages distag 10_1 , or $releasever is 10.0 and packages in
> > the
> > repo will have distag 10_0 only
>
> Don't understand this sentence....

we have define dist tag [1] in /usr/lib/rpm/macros.d/macros.dist which
is use on release version of the package [2]

Epel 10 is like rawhide , when it is branched Epel 10.0 from Epel 10,
the dist tag of Epel 10 changed from 10_0 to 10_1 . So we have 2 repos,
one with releasever=10 with dist tag 10_1  and second with
releasever=10.0 with dist tag 10_0. I think after RHEL 10.1 be released
, we will branch from Epel 10 to Epel 10.1 , again dist tag of Epel 10
change, now from 10_1 to 10_2 and a new repo is created with
releasever=10.1 , maybe repo old repo releasever=10.0 will be deleted
...
That is how I see this , maybe I'm not correct

[1]
%fedora              41
%fc41                1
%distcore            .fc%{fedora}
%dist               ... %{distcore}

[2]
Release:    1%{?dist}
> To be clear (or try to)
>
> By default (CentOS Stream, RHEL, Alma....)
>
> *    releaserver set to 10
> *    releaserver_major set to 10
> *    releaserver_minor not set
>
> So will pull from "10" repository (which is really "10.1" for EPEL)
>
> If forced to 10.0
>
> *    releaserver set to 10.0
> *    releaserver_major set to 10
> *    releaserver_minor set to 0
>
> Then will pull from "10.0" repository (until forced to another value)
> > no need $releasever_major and $releasever_minor values
>
> epel.repo uses
>
> metalink=
> https://mirrors.fedoraproject.org/metalink?repo=epel-$releasever_majo
> r${releasever_minor:+.$releasever_minor}&arch=$basearch
>
> $releasever_major${releasever_minor:+.$releasever_minor} which is
> exactly the same than $releasever (so not useful and less legible)
>
> But $releasever_major can be useful, ex
>
> gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL-$releasever_major
>
> Remi
> > > Confirmed on both RHEL-10.0-Beta and AlmaLinux-10.0-Beta
> > >
> > > https://forums.almalinux.org/t/bug-epel-repo-missing-releasever-major-and-re...
> > >
> > > Sorry, but I think EPEL-10 is broken by design

EPEL-ANNOUNCEEPEL 10.0 mass branching

[Remi Collet]

Le 05/03/2025 à 17:52, Sérgio Basto via epel-devel a écrit :
> On Wed, 2025-03-05 at 16:28 +0100, Remi Collet wrote:
> > Le 05/03/2025 à 14:58, Sérgio Basto via epel-devel a écrit :
> > > On Wed, 2025-03-05 at 13:47 +0100, Remi Collet wrote:
> > > > Le 21/02/2025 à 07:20, Remi Collet a écrit :
> > > > > AFAIK, $releasever is 10 by default.
> > >
> > > I maybe I'm seeing this wrong , but $releasever is 10 and repo will
> > > have packages distag 10_1 , or $releasever is 10.0 and packages in
> > > the
> > > repo will have distag 10_0 only
> >
> > Don't understand this sentence....
>
> we have define dist tag [1] in /usr/lib/rpm/macros.d/macros.dist which
> is use on release version of the package [2]
>
> Epel 10 is like rawhide , when it is branched Epel 10.0 from Epel 10,
> the dist tag of Epel 10 changed from 10_0 to 10_1 . So we have 2 repos,
> one with releasever=10 with dist tag 10_1  and second with
> releasever=10.0 with dist tag 10_0. I think after RHEL 10.1 be released
> , we will branch from Epel 10 to Epel 10.1 , again dist tag of Epel 10
> change, now from 10_1 to 10_2 and a new repo is created with
> releasever=10.1 , maybe repo old repo releasever=10.0 will be deleted
> ...
> That is how I see this , maybe I'm not correct

Yes, but this is about how it is built, not a problem

My concern is about how it is consumed by EL users

Remi
> [1]
> %fedora              41
> %fc41                1
> %distcore            .fc%{fedora}
> %dist               ... %{distcore}
>
> [2]
> Release:    1%{?dist}
> > To be clear (or try to)
> >
> > By default (CentOS Stream, RHEL, Alma....)
> >
> > *    releaserver set to 10
> > *    releaserver_major set to 10
> > *    releaserver_minor not set
> >
> > So will pull from "10" repository (which is really "10.1" for EPEL)
> >
> > If forced to 10.0
> >
> > *    releaserver set to 10.0
> > *    releaserver_major set to 10
> > *    releaserver_minor set to 0
> >
> > Then will pull from "10.0" repository (until forced to another value)
> > > no need $releasever_major and $releasever_minor values
> >
> > epel.repo uses
> >
> > metalink=
> > https://mirrors.fedoraproject.org/metalink?repo=epel-$releasever_majo
> > r${releasever_minor:+.$releasever_minor}&arch=$basearch
> >
> > $releasever_major${releasever_minor:+.$releasever_minor} which is
> > exactly the same than $releasever (so not useful and less legible)
> >
> > But $releasever_major can be useful, ex
> >
> > gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL-$releasever_major
> >
> > Remi
> > > > Confirmed on both RHEL-10.0-Beta and AlmaLinux-10.0-Beta
> > > >
> > > > https://forums.almalinux.org/t/bug-epel-repo-missing-releasever-major-and-re...
> > > >
> > > > Sorry, but I think EPEL-10 is broken by design

EPEL-ANNOUNCEEPEL 10.0 mass branching

[Peter Georg]

On 06/03/2025 10.12, Remi Collet wrote:
> Le 05/03/2025 à 17:52, Sérgio Basto via epel-devel a écrit :
> > On Wed, 2025-03-05 at 16:28 +0100, Remi Collet wrote:
> > > Le 05/03/2025 à 14:58, Sérgio Basto via epel-devel a écrit :
> > > > On Wed, 2025-03-05 at 13:47 +0100, Remi Collet wrote:
> > > > > Le 21/02/2025 à 07:20, Remi Collet a écrit :
> > > > > > AFAIK, $releasever is 10 by default.
> > > >
> > > > I maybe I'm seeing this wrong , but $releasever is 10 and repo will
> > > > have packages distag 10_1 , or $releasever is 10.0 and packages in
> > > > the
> > > > repo will have distag 10_0 only
> > >
> > > Don't understand this sentence....
> >
> > we have define dist tag [1] in /usr/lib/rpm/macros.d/macros.dist which
> > is use on release version of the package [2]
> >
> > Epel 10 is like rawhide , when it is branched Epel 10.0 from Epel 10,
> > the dist tag of Epel 10 changed from 10_0 to 10_1 . So we have 2 repos,
> > one with releasever=10 with dist tag 10_1  and second with
> > releasever=10.0 with dist tag 10_0. I think after RHEL 10.1 be released
> > , we will branch from Epel 10 to Epel 10.1 , again dist tag of Epel 10
> > change, now from 10_1 to 10_2 and a new repo is created with
> > releasever=10.1 , maybe repo old repo releasever=10.0 will be deleted
> > ...
> > That is how I see this , maybe I'm not correct
>
> Yes, but this is about how it is built, not a problem
>
> My concern is about how it is consumed by EL users
>
> Remi

Seems you are describing this issue: https://pagure.io/epel/issue/313
> > [1]
> > %fedora              41
> > %fc41                1
> > %distcore            .fc%{fedora}
> > %dist               ... %{distcore}
> >
> > [2]
> > Release:    1%{?dist}
> > > To be clear (or try to)
> > >
> > > By default (CentOS Stream, RHEL, Alma....)
> > >
> > > *    releaserver set to 10
> > > *    releaserver_major set to 10
> > > *    releaserver_minor not set
> > >
> > > So will pull from "10" repository (which is really "10.1" for EPEL)
> > >
> > > If forced to 10.0
> > >
> > > *    releaserver set to 10.0
> > > *    releaserver_major set to 10
> > > *    releaserver_minor set to 0
> > >
> > > Then will pull from "10.0" repository (until forced to another value)
> > > > no need $releasever_major and $releasever_minor values
> > >
> > > epel.repo uses
> > >
> > > metalink=
> > > https://mirrors.fedoraproject.org/metalink?repo=epel-$releasever_majo
> > > r${releasever_minor:+.$releasever_minor}&arch=$basearch
> > >
> > > $releasever_major${releasever_minor:+.$releasever_minor} which is
> > > exactly the same than $releasever (so not useful and less legible)
> > >
> > > But $releasever_major can be useful, ex
> > >
> > > gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL-$releasever_major
> > >
> > > Remi
> > > > > Confirmed on both RHEL-10.0-Beta and AlmaLinux-10.0-Beta
> > > > >
> > > > > https://forums.almalinux.org/t/bug-epel-repo-missing-releasever- 
> > > > > major-and-releasever-minor-values/5566/3?u=remi
> > > > >
> > > > > Sorry, but I think EPEL-10 is broken by design

EPEL-ANNOUNCEEPEL 10.0 mass branching

[Sérgio Basto]

On Thu, 2025-03-06 at 10:12 +0100, Remi Collet wrote:
> Le 05/03/2025 à 17:52, Sérgio Basto via epel-devel a écrit :
> > On Wed, 2025-03-05 at 16:28 +0100, Remi Collet wrote:
> > > Le 05/03/2025 à 14:58, Sérgio Basto via epel-devel a écrit :
> > > > On Wed, 2025-03-05 at 13:47 +0100, Remi Collet wrote:
> > > > > Le 21/02/2025 à 07:20, Remi Collet a écrit :
> > > > > > AFAIK, $releasever is 10 by default.
> > > >
> > > > I maybe I'm seeing this wrong , but $releasever is 10 and repo
> > > > will
> > > > have packages distag 10_1 , or $releasever is 10.0 and packages
> > > > in
> > > > the
> > > > repo will have distag 10_0 only
> > >
> > > Don't understand this sentence....
> >
> > we have define dist tag [1] in /usr/lib/rpm/macros.d/macros.dist
> > which
> > is use on release version of the package [2]
> >
> > Epel 10 is like rawhide , when it is branched Epel 10.0 from Epel
> > 10,
> > the dist tag of Epel 10 changed from 10_0 to 10_1 . So we have 2
> > repos,
> > one with releasever=10 with dist tag 10_1  and second with
> > releasever=10.0 with dist tag 10_0. I think after RHEL 10.1 be
> > released
> > , we will branch from Epel 10 to Epel 10.1 , again dist tag of Epel
> > 10
> > change, now from 10_1 to 10_2 and a new repo is created with
> > releasever=10.1 , maybe repo old repo releasever=10.0 will be
> > deleted
> > ...
> > That is how I see this , maybe I'm not correct
>
> Yes, but this is about how it is built, not a problem
>
> My concern is about how it is consumed by EL users

RHEL 10.x consume epel 10.x
Centos Stream 10 consume epel 10

Seems to me more simpler than in EL 9
> Remi
> > [1]
> > %fedora              41
> > %fc41                1
> > %distcore            .fc%{fedora}
> > %dist               ... %{distcore}
> >
> > [2]
> > Release:    1%{?dist}
> > > To be clear (or try to)
> > >
> > > By default (CentOS Stream, RHEL, Alma....)
> > >
> > > *    releaserver set to 10
> > > *    releaserver_major set to 10
> > > *    releaserver_minor not set
> > >
> > > So will pull from "10" repository (which is really "10.1" for
> > > EPEL)
> > >
> > > If forced to 10.0
> > >
> > > *    releaserver set to 10.0
> > > *    releaserver_major set to 10
> > > *    releaserver_minor set to 0
> > >
> > > Then will pull from "10.0" repository (until forced to another
> > > value)
> > > > no need $releasever_major and $releasever_minor values
> > >
> > > epel.repo uses
> > >
> > > metalink=
> > > https://mirrors.fedoraproject.org/metalink?repo=epel-$releasever_majo
> > > r${releasever_minor:+.$releasever_minor}&arch=$basearch
> > >
> > > $releasever_major${releasever_minor:+.$releasever_minor} which is
> > > exactly the same than $releasever (so not useful and less
> > > legible)
> > >
> > > But $releasever_major can be useful, ex
> > >
> > > gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL-
> > > $releasever_major
> > >
> > > Remi
> > > > > Confirmed on both RHEL-10.0-Beta and AlmaLinux-10.0-Beta
> > > > >
> > > > > https://forums.almalinux.org/t/bug-epel-repo-missing-releasever-major-and-re...
> > > > >
> > > > > Sorry, but I think EPEL-10 is broken by design

EPEL-ANNOUNCEEPEL 10.0 mass branching

[Sérgio Basto]

On Thu, 2025-02-20 at 06:15 -0800, Troy Dawson wrote:
> On Thu, Feb 20, 2025 at 12:10 AM Remi Collet
>  wrote:
> > Le 18/02/2025 à 09:13, Carl George via epel-announce a écrit :
> > > Hello EPEL packagers,
> > >
> > > Later today (2025-02-18), Release Engineering will branch
> >
> > epel10.0
> > > from epel10, in accordance with our overall branching strategy
> >
> > for
> > > EPEL 10.
> > >
> > > https://docs.fedoraproject.org/en-US/epel/branches/#_epel_10
> >
> > Can you please confirm if 10.0 new builds will be available
> > in "10" (for CentOS Stream users) ?
> >
> > Or do I have to build in both branches ?
>
> Currently there are two branches.
> epel10
> epel10.0
>
> Everything built in epel10 will have a dist-tag of epel10_1 and will
> go into the epel10 repo.  This is consumed by CentOS Stream 10.
>
> Everything build in epel10.0 will have a dist-tag of epel10_0 and
> will go into the epel10.0 repo.  This will be consumed by RHEL 10.0
> only, not CentOS Stream.

OK , seems to me a better solution than epel-next
> So it depends on what you want.
> If you care only about CentOS Stream 10, then just epel10 is needed.
> If you want it to be in both RHEL 10.0+ and CentOS Stream 10, then
> yes, you have to build it in both branches.
>
> Do not build it in epel10.0 only.  The build will not transfer over.
>
> Troy
> p.s. If you are a Fedora package maintainer, picture this being right
> after the branching point from rawhide.

[Sérgio Basto]

On Tue, 2025-02-18 at 02:13 -0600, Carl George wrote:
> Hello EPEL packagers,
>
> Later today (2025-02-18), Release Engineering will branch epel10.0
> from epel10, in accordance with our overall branching strategy for
> EPEL 10.
>
> https://docs.fedoraproject.org/en-US/epel/branches/#_epel_10
>
> During the branching, we will temporarily disable builds to the
> epel10-candidate target, which is used when you run `fedpkg build`
> from the epel10 branch.  If you are trying to create a build and
> receive an error about a target not existing, please try again later
> in the day.  Because this is the first time we are doing an EPEL mass
> branching, we don't know precisely how long it will take or how long
> we will need to disable the builds for.

When we want update epel for both RHEL and Centos (stream) i.e. build
on el9 and not el9-next,  for el10 should we build on epel10 or
epel10.0 ?

[Fabio Valentini]

On Mon, Mar 3, 2025 at 1:53 AM Sérgio Basto via epel-devel
 wrote:
> On Tue, 2025-02-18 at 02:13 -0600, Carl George wrote:
> > Hello EPEL packagers,
> >
> > Later today (2025-02-18), Release Engineering will branch epel10.0
> > from epel10, in accordance with our overall branching strategy for
> > EPEL 10.
> >
> > https://docs.fedoraproject.org/en-US/epel/branches/#_epel_10
> >
> > During the branching, we will temporarily disable builds to the
> > epel10-candidate target, which is used when you run `fedpkg build`
> > from the epel10 branch.  If you are trying to create a build and
> > receive an error about a target not existing, please try again later
> > in the day.  Because this is the first time we are doing an EPEL mass
> > branching, we don't know precisely how long it will take or how long
> > we will need to disable the builds for.
>
> When we want update epel for both RHEL and Centos (stream) i.e. build
> on el9 and not el9-next,  for el10 should we build on epel10 or
> epel10.0 ?

The short answer is "both if you want both" :)

Since epel10.0 has already been branched off of epel10, you will need
to submit a build from both the epel10 branch and the epel10.0 branch
if you still want a change to land in both EPEL 10.0 (for RHEL 10.0)
and in EPEL 10 (for CentOS Stream 10).
If you only build from the epel10 branch, it will only land in what
will become epel10.1 once that is branched off in ~6 months (similar
to what happens when you only build in rawhide - it will trickle down
to stable branches only at the next branch point).

Fabio

[Sérgio Basto]

On Mon, 2025-03-03 at 15:05 +0100, Fabio Valentini wrote:
> On Mon, Mar 3, 2025 at 1:53 AM Sérgio Basto via epel-devel
>  wrote:
> > On Tue, 2025-02-18 at 02:13 -0600, Carl George wrote:
> > > Hello EPEL packagers,
> > >
> > > Later today (2025-02-18), Release Engineering will branch
> > > epel10.0
> > > from epel10, in accordance with our overall branching strategy
> > > for
> > > EPEL 10.
> > >
> > > https://docs.fedoraproject.org/en-US/epel/branches/#_epel_10
> > >
> > > During the branching, we will temporarily disable builds to the
> > > epel10-candidate target, which is used when you run `fedpkg
> > > build`
> > > from the epel10 branch.  If you are trying to create a build and
> > > receive an error about a target not existing, please try again
> > > later
> > > in the day.  Because this is the first time we are doing an EPEL
> > > mass
> > > branching, we don't know precisely how long it will take or how
> > > long
> > > we will need to disable the builds for.
> >
> > When we want update epel for both RHEL and Centos (stream) i.e.
> > build
> > on el9 and not el9-next,  for el10 should we build on epel10 or
> > epel10.0 ?
>
> The short answer is "both if you want both" :)
>
> Since epel10.0 has already been branched off of epel10, you will need
> to submit a build from both the epel10 branch and the epel10.0 branch
> if you still want a change to land in both EPEL 10.0 (for RHEL 10.0)

RHEL 10.0 which is RHEL 10 Beta ?
> and in EPEL 10 (for CentOS Stream 10).
> If you only build from the epel10 branch, it will only land in what
> will become epel10.1 once that is branched off in ~6 months (similar
> to what happens when you only build in rawhide - it will trickle down
> to stable branches only at the next branch point).

I like the schema , seems to me that is more correct , any plan use the
same for EL 9 ?

[Carl George]

On Mon, Mar 3, 2025 at 1:36 PM Sérgio Basto via epel-devel
 wrote:
> On Mon, 2025-03-03 at 15:05 +0100, Fabio Valentini wrote:
> > On Mon, Mar 3, 2025 at 1:53 AM Sérgio Basto via epel-devel
> >  wrote:
> > > On Tue, 2025-02-18 at 02:13 -0600, Carl George wrote:
> > > > Hello EPEL packagers,
> > > >
> > > > Later today (2025-02-18), Release Engineering will branch
> > > > epel10.0
> > > > from epel10, in accordance with our overall branching strategy
> > > > for
> > > > EPEL 10.
> > > >
> > > > https://docs.fedoraproject.org/en-US/epel/branches/#_epel_10
> > > >
> > > > During the branching, we will temporarily disable builds to the
> > > > epel10-candidate target, which is used when you run `fedpkg
> > > > build`
> > > > from the epel10 branch.  If you are trying to create a build and
> > > > receive an error about a target not existing, please try again
> > > > later
> > > > in the day.  Because this is the first time we are doing an EPEL
> > > > mass
> > > > branching, we don't know precisely how long it will take or how
> > > > long
> > > > we will need to disable the builds for.
> > >
> > > When we want update epel for both RHEL and Centos (stream) i.e.
> > > build
> > > on el9 and not el9-next,  for el10 should we build on epel10 or
> > > epel10.0 ?
> >
> > The short answer is "both if you want both" :)
> >
> > Since epel10.0 has already been branched off of epel10, you will need
> > to submit a build from both the epel10 branch and the epel10.0 branch
> > if you still want a change to land in both EPEL 10.0 (for RHEL 10.0)
>
> RHEL 10.0 which is RHEL 10 Beta ?

Not exactly.  RHEL 10 Beta essentially functions like a minor version
before RHEL 10.0.  Nothing in EPEL has been built against it, so
you'll probably run into edge cases of missing dependencies and other
oddities.  If you want to test EPEL 10.0 updates, your best bet at
this point to use CentOS Stream 10 and override releasever to 10.0.
This isn't perfectly correct either, but it is quite a bit closer to
RHEL 10.0 than RHEL 10 Beta is at this point in time.

Also remember that it is ok to just build for EPEL 10.1, unless you're
specifically fixing a bug in an EPEL 10.0 package.  You don't have to
build for both if you don't need to.  You can treat EPEL 10.0 similar
to how you would treat a Fedora branch after the updates-testing
activation.  It's ok to defer non-essential updates to 10.1.  This is
similar to doing an update in Fedora right now.  If you're making a
non-essential change, it probably shouldn't be done in F42, and
instead only be done in rawhide so that it is deferred to F43.  The
EPEL Steering Committee has been discussing modifying the EPEL updates
policy to capture this nuance, modeled after the Fedora updates
policy.
> > and in EPEL 10 (for CentOS Stream 10).
> > If you only build from the epel10 branch, it will only land in what
> > will become epel10.1 once that is branched off in ~6 months (similar
> > to what happens when you only build in rawhide - it will trickle down
> > to stable branches only at the next branch point).
>
> I like the schema , seems to me that is more correct , any plan use the
> same for EL 9 ?

I'm happy to hear you like it.  It was designed to work more similar
to Fedora.  However, I'm afraid it would be far too disruptive to port
EPEL 9 to the same structure midway through its lifecycle.  I'm happy
to discuss it further if people have specific ideas about how such a
transition would work, but for now I consider this new scheme to be
EPEL 10+ only.
> --
> Sérgio M. B.
> --
> _______________________________________________
> epel-devel mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> 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/[e-mail]...
> Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue