2024-03-24 19:18:25 +00:00
|
|
|
RHEL_MAJOR = 10
|
|
|
|
RHEL_MINOR = 0
|
2020-04-29 21:12:02 +00:00
|
|
|
|
|
|
|
#
|
|
|
|
# RHEL_RELEASE
|
|
|
|
# -------------
|
|
|
|
#
|
|
|
|
# Represents build number in 'release' part of RPM's name-version-release.
|
|
|
|
# name is <package_name>, e.g. kernel
|
|
|
|
# version is upstream kernel version this kernel is based on, e.g. 4.18.0
|
|
|
|
# release is <RHEL_RELEASE>.<dist_tag>[<buildid>], e.g. 100.el8
|
|
|
|
#
|
|
|
|
# Use this spot to avoid future merge conflicts.
|
|
|
|
# Do not trim this comment.
|
2024-10-29 06:51:51 +00:00
|
|
|
RHEL_RELEASE = 27
|
2023-04-12 14:35:24 +00:00
|
|
|
|
|
|
|
#
|
|
|
|
# RHEL_REBASE_NUM
|
|
|
|
# ----------------
|
|
|
|
#
|
|
|
|
# Used in RPM version string for Gemini kernels, which dont use upstream
|
|
|
|
# VERSION/PATCHLEVEL/SUBLEVEL. The number represents rebase number for
|
|
|
|
# current MAJOR release.
|
|
|
|
#
|
|
|
|
# Use this spot to avoid future merge conflicts.
|
|
|
|
# Do not trim this comment.
|
|
|
|
RHEL_REBASE_NUM = 1
|
|
|
|
|
2022-05-02 13:44:51 +00:00
|
|
|
|
|
|
|
#
|
|
|
|
# ZSTREAM
|
|
|
|
# -------
|
|
|
|
#
|
|
|
|
# This variable controls whether we use zstream numbering or not for the
|
|
|
|
# package release. The zstream release keeps the build number of the last
|
|
|
|
# build done for ystream for the Beta milestone, and increments a second
|
|
|
|
# number for each build. The third number is used for branched builds
|
|
|
|
# (eg.: for builds with security fixes or hot fixes done outside of the
|
|
|
|
# batch release process).
|
|
|
|
#
|
|
|
|
# For example, with ZSTREAM unset or set to "no", all builds will contain
|
|
|
|
# a release with only the build number, eg.: kernel-<kernel version>-X.el*,
|
|
|
|
# where X is the build number. With ZSTREAM set to "yes", we will have
|
|
|
|
# builds with kernel-<kernel version>-X.Y.Z.el*, where X is the last
|
|
|
|
# RHEL_RELEASE number before ZSTREAM flag was set to yes, Y will now be the
|
|
|
|
# build number and Z will always be 1 except if you're doing a branched build
|
|
|
|
# (when you give RHDISTGIT_BRANCH on the command line, in which case the Z
|
|
|
|
# number will be incremented instead of the Y).
|
|
|
|
#
|
|
|
|
ZSTREAM ?= no
|
2020-04-29 21:12:02 +00:00
|
|
|
|
|
|
|
#
|
|
|
|
# Early y+1 numbering
|
|
|
|
# --------------------
|
|
|
|
#
|
|
|
|
# In early y+1 process, RHEL_RELEASE consists of 2 numbers: x.y
|
|
|
|
# First is RHEL_RELEASE inherited/merged from y as-is, second number
|
|
|
|
# is incremented with each build starting from 1. After merge from y,
|
|
|
|
# it resets back to 1. This way y+1 nvr reflects status of last merge.
|
|
|
|
#
|
|
|
|
# Example:
|
|
|
|
#
|
|
|
|
# rhel8.0 rhel-8.1
|
|
|
|
# kernel-4.18.0-58.el8 --> kernel-4.18.0-58.1.el8
|
|
|
|
# kernel-4.18.0-58.2.el8
|
|
|
|
# kernel-4.18.0-59.el8 kernel-4.18.0-59.1.el8
|
|
|
|
# kernel-4.18.0-60.el8
|
|
|
|
# kernel-4.18.0-61.el8 --> kernel-4.18.0-61.1.el8
|
|
|
|
#
|
|
|
|
#
|
|
|
|
# Use this spot to avoid future merge conflicts.
|
|
|
|
# Do not trim this comment.
|
|
|
|
EARLY_YSTREAM ?= no
|
|
|
|
EARLY_YBUILD:=
|
|
|
|
EARLY_YRELEASE:=
|
|
|
|
ifneq ("$(ZSTREAM)", "yes")
|
|
|
|
ifeq ("$(EARLY_YSTREAM)","yes")
|
|
|
|
RHEL_RELEASE:=$(RHEL_RELEASE).$(EARLY_YRELEASE)
|
|
|
|
endif
|
|
|
|
endif
|