Add Backport for installonlypkgs to tdnf for Mariner 2.0

[sameluch]

Merge Checklist

All boxes should be checked before merging the PR (just tick any boxes which don't apply to this PR)

• The toolchain has been rebuilt successfully (or no changes were made to it)
• The toolchain/worker package manifests are up-to-date
• Any updated packages successfully build (or no packages were changed)
• Packages depending on static components modified in this PR (Golang, *-static subpackages, etc.) have had their Release tag incremented.
• Package tests (%check section) have been verified with RUN_CHECK=y for existing SPEC files, or added to new SPEC files
• All package sources are available
• cgmanifest files are up-to-date and sorted (./cgmanifest.json, ./toolkit/scripts/toolchain/cgmanifest.json, .github/workflows/cgmanifest.json)
• LICENSE-MAP files are up-to-date (./SPECS/LICENSES-AND-NOTICES/data/licenses.json, ./SPECS/LICENSES-AND-NOTICES/LICENSES-MAP.md, ./SPECS/LICENSES-AND-NOTICES/LICENSE-EXCEPTIONS.PHOTON)
• All source files have up-to-date hashes in the *.signatures.json files
• sudo make go-tidy-all and sudo make go-test-coverage pass
• Documentation has been updated to match any changes to the build system
• Ready to merge

---

Summary

What does the PR accomplish, why was it needed?
Backport patch for installonlypkgs functionality for tdnf in Mariner 2.0 to allow for kernel modules to be maintained post tdnf upgrade.

Change Log

• Backport patch for installonlypkgs functionality for tdnf in Mariner 2.0
• Add kernel and kernel-* packages to tdnf.conf in installonlypkgs

Does this affect the toolchain?

YES

Test Methodology

• Local Build
• Main Pipeline Builds: 1st Run, 2nd Run

[rlmenge]

Just tested these changes. They respect installonly_limit but have different behavior then dnf. The patched tdnf removes the "rpm installed longest ago" while dnf removes the "oldest versioned rpm" installed. In both cases however, only 3 kernels are ever installed.

Dnf behavior:

$ rpm -qa kernel
5.15.137.1-1
5.15.138.1-1
5.15.131.1-1

$ dnf install -y kernel-5.15.136.1-1
#5.15.131.1-1 was removed. 

$ rpm -qa kernel
5.15.137.1-1
5.15.138.1-1
5.15.136.1-1

tdnf behavior:

$ rpm -qa kernel
5.15.137.1-1
5.15.138.1-1
5.15.131.1-1

$ tdnf install -y kernel-5.15.136.1-1
# 5.15.137.1-1 was removed. 

$ rpm -qa kernel
5.15.138.1-1
5.15.131.1-1
5.15.136.1-1

[rlmenge]

5.15.138.1-1
5.15.131.1-1
5.15.136.1-1

There is an upstream request for parity with dnf here: vmware/tdnf#460

[gjswalling]

do we want this off by default? I think it's enabled by default for DNF, per here:
The clean_requirements_on_remove switch is on by default in DNF.

[gjswalling]

I guess it would be good to stay consistent with how tdnf has been working in Mariner, regardless of going with yum vs. dnf.

[sameluch]

By default this is off in tdnf and we have not changed it, see here for the upstream file. This would be a reasonable change in behavior that we may not want for 2.0. We may be able to investigate for 3.0 as it could potentially cause some splash by turning it on now.

[sameluch]

Bug for context: https://microsoft.visualstudio.com/OS/_workitems/edit/42337948/?triage=true

[Camelron]

Thanks for this, lgtm.