Add Rocky 10.1 aarch64 files for Docker Hub

[rlhennig]

oci-import is used for building Rocky images by the Docker Hub team. @tianon gave examples:

https://github.com/tianon/rockylinux-oci-import-sample

This PR is to add the necessary files for the latest Rocky 10.1 Base build for aarch64.

[NeilHanlon]

Hey @rlhennig, thanks for working on this and for the context about moving to OCI-native format based on the Docker Hub team's recommendations. That direction makes sense, and I can see this aligns with the Kiwi-based builds we're using for all Rocky versions now.

I appreciate you getting hands-on with this, but I think we might be approaching this backwards. We actually already have tooling in the tools/ directory that's designed to handle this workflow - including the recent Kiwi support we've been building out. Rather than manually creating PRs for individual build artifacts, we should be using/improving that automation.

A challenge I'm wrestling with is that we can't really merge this contribution via PR because PRs cannot create new branches on the target repository. We don't want to merge this into main but rather into the named version branch that Docker Hub will reference. This is a workflow issue with the repo structure itself, not your contribution. One potential solution would be to collapse the current (Major, Minor, Date, Variant, Arch) 5-tuple branch naming scheme down to something like (Major, Minor) or (Major, Minor, Date), which would significantly reduce the administrative overhead of creating branches for each combination.

My preference here is to step back and focus on the overall problem we're trying to solve rather than addressing individual branches piecemeal. Speaking from experience with this project, that approach leads to technical debt accumulating faster than we can pay it down, especially given EL's fairly frequent release cycle. The next releases are only a couple of months away and we typically freeze big changes for at least a few weeks prior, so now is actually the right time to tackle this properly.

I'm thinking the solution probably looks something like:

• A config file in main controlling what branches should exist
• GitHub Actions to create branches from a template on merge
• Anyone can then PR to those branches with the required content, using the tools in main
• These branches become the source of truth for hydrating all registries - we build (import), sign, and push to all the registries we control (quay.io, docker.io/rockylinux, etc.)
• Docker Library official images reference these same branches for their import process
• Actions run on a schedule to fetch the latest images (if they exist) and automatically prepare PRs for approval
• Ideally, this extends beyond just Container images to our other cloud images as well

Honestly, a fresh repo might be the cleanest path forward. This one has accumulated a lot of historical data and structural decisions that we probably don't need to carry forward. Starting fresh would let us build the right architecture from day one, where the branches serve as the canonical artifact store for all downstream distribution.

What do you think? I am interested in your thoughts on this approach.