 |
9.5 is the current release of Rocky Linux 9, there are no "older" packages in 9.5. |
 |
Thank you for the report. This is a request we get regularly. While we would like to have the repodata available for general use, we cannot at this time due to how mirror manager maintains its mirror list. We do not want a case of it picking up the vault repodata, and thus it remains locked down until the next point release. If you are simply mirroring this content internally, you may consider rsync to make it easier for you to get this older data, as it is freely accessible. The endpoint is msync.rockylinux.org. |
|
|
For decades we have build tools around a fundamental ability to rebuild bare metal, virtual machine, and container images. While it is always recommended to use the latest available asset packages, it is unreasonable to expect users to be able to keep pace and deploy updates at such a rate. The ability to rebuild an image from a "frozen" list of asset packages is a valuable method to work with different users. We have always been able to perform this task with the available repositories using the current minor release repositories or the vaulted repositories for discontinued (vaulted) minor releases. This ended with Rocky Linux 9 when support for versions of an asset package stopped be included in the repos when a newer version was introduced. Having all versions of an asset package that were made available with a minor release for the lifespan of the minor release was supported until Rocky Linux 9. We have been waiting for this to be addressed as was documented under the version policy document (https://wiki.rockylinux.org/rocky/repo/#version-policy). As this configuration within the repositories for Rocky Linux 9 are still unable, it was found that the older versions of the asset packages for the current minor release were appearing in the vault repository for the release. These packages are downloadable using a web browser GUI; however, they are not accessible via a dnf/yum configuration setting because the repodata is not available/accessible. For example: while shadow-utils-4.9-10.el9_5.x86_64.rpm is the current asset package available under the current(active) minor release repository for 9.5 (http://dl.rockylinux.org/pub/rocky/9.5/BaseOS/x86_64/os/Packages/s/), the previous version (shadow-utils-4.9-9.el9.x86_64.rpm) is only available from the discontinued(vaulted) minor release repository for 9.5 (https://download.rockylinux.org/vault/rocky/9.5/BaseOS/x86_64/os/Packages/s/). There are users that may still need this older version that was released as part of 9.5. Rsyncing is a method; however, it not as useful as the mirror cache repo method which allows users to stay current with the repo and will download and store only what is being used (thereby offloading the primary repo of mulitple requests). The best solution would have been to support all the versions of a minor release within the current(active) repo; however, have the older versions from the minor release available with the vault would be almost as good, but it requires dnf/yum repodata access within the repo (whether it is updated whenever a new item is pulled in or with simply a daily cron would be better than having nothing here until the entire minor release is vaulted). |
|
|
>For decades we have build tools around a fundamental ability to rebuild bare metal, virtual machine, and container images. While it is always recommended to use the latest available asset packages, it is unreasonable to expect users to be able to keep pace and deploy updates at such a rate. The ability to rebuild an image from a "frozen" list of asset packages is a valuable method to work with different users. This doesn't solve everything you're likely wanting, but reproducible system builds are a common thing for users of Rocky Linux, and that is why we provide a "kickstart" repository, which is an exact snapshot of when that minor release came out. Every repository contains an "os" directory (up to date) and a "kickstart" (snapshot) directory. Perhaps using the kickstart repository would help in some of your scenarios. >As this configuration within the repositories for Rocky Linux 9 are still unable, it was found that the older versions of the asset packages for the current minor release were appearing in the vault repository for the release. These packages are downloadable using a web browser GUI; however, they are not accessible via a dnf/yum configuration setting because the repodata is not available/accessible. This is simply due to how Mirror Manager works. It looks at repodata to determine what is up to date and then checks if the 100+ mirrors we have are also synced. We do not want to hit a potential race condition where the vault is seen as the primary "up to date" repodata and thus, invalidating the 100+ mirrors we have. As for why the mirror manager checks the vault, it is because we keep the older versions linked to the vault for those who still use the mirror list for their unsupported systems, and thus, it still has to scan regularly (even though there are zero changes to unsupported releases) and then check the associated mirrors syncing from the vault. >The best solution would have been to support all the versions of a minor release within the current(active) repo This would be the best solution, but the design of yumrepofs in peridot (build system) was not designed for this initially. We have not had time, as a volunteer community project, to address this in the peridot build system for multiple versions in the repositories. We have asked for community help, but we haven't received interest. With Rocky Linux 10 coming up, our build system is getting a full rework, which will ultimately address this (and many other) issues. Most of the development team will be at CentOS Connect and FOSDEM for general planning and roadmap discussion, and this is one of the topics. |
|
|
Ok, we were hoping that it was possible based on the fact that the repodata directory was present. As we did not have access to the directory, did not know what was available. As this is not being pursued based on community resources and interest, you can close this ticket. Appreciate the time spent explaining the reasons for the repo config/behavior for Rocky Linux 9. It is not necessary, but a short statement regarding this in the Rocky version policy page may help reduce future inquiries regarding this topic. |
- Anonymous
