Override releasever_{major,minor} with system-release provides

[evan-goode]

The releasever_major and releasever_minor substitution variables are usually derived by splitting releasever on the first .. However, to support EPEL 10 [1], we would like a way for distributions to override these values. Specifically, we would like RHEL 10 to have a releasever of 10 with a releasever_major of 10 and a releasever_minor of 0 (later incrementing to 1, 2, to correspond with the RHEL minor version).

This commit adds a new API function, detect_releasevers, which derives releasever, releasever_major, and releasever_minor from virtual provides on the system-release package (any of DISTROVERPKG). The detection of releasever is unchanged. releasever_major and releasever_minor are specified by the versions of the system-release-major and system-release-minor provides, respectively.

If the user specifies a --releasever=X.Y on the command line, the distribution settings for releasever, releasever_major, and releasever_minor will all be overridden: releasever will be set to X.Y, releasever_major will be set to X, and releasever_minor will be set to Y, same as before.

If a user wants to specify a custom releasever_{major,minor}, they have to set all three with --setopt=releasever=X --setopt=releasever_major=Y --setopt=releasever_minor=z, taking care to put releasever_major and releasever_minor after releasever so they are not overridden. This is admittedly not ideal, but I can't think of another solution to this problem that preserves the following properties:

1. If they are not overridden, releasever_{major,minor} are derived by splitting releasever. This behavior was added in Split $releasever to $releasever_major and $releasever_minor #1989.
2. If --releasever is specified on the command line, releasever_{major,minor} should be set accordingly, even if releasever{major_minor} are specified by provides in the distribution system-release package.
3. The user should somehow be able to specify their own custom releasever, releasever_major, and releasever_minor.

Maybe we could add --releasever_major= and --releasever_minor options that take priority over --releasever to improve point (3).

Another caveat to allowing overriding releasever_{major,minor} is existing API users using detect_releasever. Take this snippet from our doc/examples/install_extension.py:

    with dnf.Base() as base:
        # Substitutions are needed for correct interpretation of repo files.
        RELEASEVER = dnf.rpm.detect_releasever(base.conf.installroot)
        base.conf.substitutions['releasever'] = RELEASEVER

Now, in order to detect the correct releasever_{major,minor}, the correct code would be

    with dnf.Base() as base:
        # Substitutions are needed for correct interpretation of repo files.
        RELEASEVER, MAJOR, MINOR = dnf.rpm.detect_releasevers(base.conf.installroot)
        base.conf.substitutions['releasever'] = RELEASEVER
        if MAJOR is not None:
            base.conf.substitutions['releasever_major']
        if MINOR is not None:
            base.conf.substitutions['releasever_minor']

Requires rpm-software-management/libdnf#1689.

[1] https://issues.redhat.com/browse/RHEL-68034

[carlwgeorge]

Would it make more sense to use system-release(releasever_major) and system-release(releasever_minor) for the provides for consistency with the existing system-release(releasever)?

[evan-goode]

Ah, yes, those are better, I changed it. DNF respects either system-release or system-release(releasever) but looks like libdnf's dnf_context_set_os_release only looks at system-release(releasever) and not system-release.