Mirrored rocky-release repository
Go to file
2022-06-30 14:45:40 -07:00
SOURCES remove testing key from repo files 2022-06-30 14:39:52 -07:00
SPECS Bump to 9.0-2.1 to prepare for release 2022-06-30 14:45:40 -07:00
.gitignore fix .gitignore 2021-05-25 20:14:20 -07:00
.rocky-release.metadata initial commit 2021-02-01 00:12:25 -07:00
code add code 2021-09-13 15:35:30 -07:00
id_verify init rocky 9 2021-10-05 00:52:23 -07:00
README.md use conditionals instead 2022-05-08 08:40:04 -07:00

Release package - All PR's should be against original/rpms/rocky-release

Notes for Packagers/Builders

This package produces multiple variants of rocky-release:

  • Stable: rocky-release, rocky-repos, rocky-gpg-keys, etc

  • LookAhead: All packages appended with -lookahead

  • Beta: All packages appended with -Beta

  • If --with=rllookahead or --with=rlbeta are set in mock, those variants are built

  • If both are set the same time, build will fail

When --with=rllookahead is set the minor version will typically be y+1. So if the current stable is X.0, the next would be X.1.

For pre-releases/beta, both packages should produce X.Y until changed in the spec.

The rllh macro may be versioned out for future use. It does not have to be explicitly set.

A rllh_minor macro may be introduced in the future.

How does this benefit us?

It allows us to track future minor releases from Stream and see how it will affect us going forward. When a minor release is being branched, the "lookahead" files can just be copied and a new "stable" release is made in preparation. The beta of each RHEL tends to stick around for a month before a release is done, which makes it easier to make sure everything "stays in line" for the most part.

What about after the five year mark?

LookAhead will no longer be produced as the major version will then be in maintenance only mode.

What is the rloverride macro?

This simply sets the dist tag to .el%{major}.override and changes the ID="..." tag in /etc/os-release to read as rhel rather than rocky. This helps us perform very specific builds that cannot otherwise be debranded properly, eg dotnet. This should also change the initial macros to only provide %rhel and not CentOS or any other derivative macro name, as some packages specifically look for these macros being set as well and also applies to those packages that cannot be properly debranded or when debranding has not visual or functional benefit.