On Wed, 2026-03-04 at 20:19 +0100, Nicolas Chauvet via rpmfusion-
developers wrote:
> Le mar. 3 mars 2026 à 17:23, Andrew Bauer via rpmfusion-developers
> <[email protected]> a écrit :
> >
> > My apologies. I don't think my last reply posted to the devel list.
> >
> > If I understand, it sounds like you are willing to create a new
> > el10 target, or modify the existing el10 target, to build against a
> > rhel10 clone, rather than stream. If that is indeed the case, then
> > I can certainly wait for this to happen.
> Yep, this is modified and I've succeeded with a scratch build, so now
> the default el10 target is now building against a rhel10 clone
> instead
> of centos stream.
>
> One can still build agaist centos-stream by using:
> rfpkg build --target=el10-next-free (or nonfree, when relevant).
EPEL 10 now finally follows the same model as CentOS Stream. Now epel10
acts as the “rawhide”, and we have branches such as epel10_0, epel10_1,
epel10_2, and so on.
When the RHEL minor version is updated, for example from RHEL 10.2 to
RHEL 10.3, what is in epel10 is forked as epel10_3. So I propose that
the target/tag, instead of being epel10-next, be epel10-stable, and on
each RHEL version update epel10 be merged / copied to epel10-stable.
Here I am proposing that instead of having branches 10.0, 10.1, 10.2,
etc., we have only a single branch called epel10-stable.
Therefore, if we want to build for the RHEL (stable release), we should
build for both branches: epel10 and epel10-stable, and what is in
epel10 will reach the stable branch on the next RHEL version update.
Also in the {?dist} of the rpm spec (Release: 1%{?dist}), we can change
the number so that the epel10 target uses "10_4" and the epel10-stable
target uses "10_3"
but yes, the logic will be: if CentOS Stream is at 10.4 and RHEL is at
10.3, and you want to update up to 10.2, you build for the targets
10.4, 10.3, and 10.2, I think.
>
> That said, since we do not yet have separate branch one have to bump
> the release tag in order to differentiate the build.
> Ideally we could use el10_2 like epel, but we are more likely to use
> the el10.next tag instead (like epel9-next) because we are unlikely
> to
> track specific branches...
>
> > If this isn't the case then let me know that as well. I will back
> > out the qt6 changes from the specfile and continue building against
> > qt5. I'll hold off on qt6 until rhel 10.2 is released (june?
> > July?).
> >
> > Please let me know.
> >
> > NOTE:
> > It looks like I ran into this same issue with the kmod-nvidia
> > package. It is uninstallable on el10 due to requiring a kernel that
> > does not yet exist.
>
> We have some limited support for pre-built kmod on EL, but one should
> use akmod-nvidia instead. Maybe we should rework the kmods headers to
> default to akmods also for EL branches.
> _______________________________________________
> rpmfusion-developers mailing list --
> [email protected]
> To unsubscribe send an email to
> [email protected]
--
Sérgio M. B.
_______________________________________________
rpmfusion-developers mailing list -- [email protected]
To unsubscribe send an email to [email protected]
