Where can I found old versions of the RPMs for Rocky Linux 9? I can only seem to find the latest and greatest under Index of /pub/rocky/9.0/
I am setting up a project where I will build a kernel module and package it in an RPM. Since kernel versions change, I want to install the kernel-devel package that corresponds to the 9.0 version (and later also for 9.1, 9.2, etc.). We are adapting from a similar setup that was running on CentOS 7, where we installed all base kernel-devel packages for the 7.x versions. To be able to target a base 9.0 release I want to install the base 9.0 kernel-devel RPM (5.14.0-70.13.1), but I am unable to locate this anywhere.
Yes, but I can only find 5.14.0-70.30.1.el9_0 on the download site, not the 5.14.0-70.26.1.el9_0 I got when I installed my dev VM a couple of weeks ago, nor the 5.14.0-70.13.1 version that Wikipedia lists as the one that came with the initial 9.0 release.
I am looking for a stable download URL that I can get the specific version from, now and later when I set up build machines. CentOS 7 had a basic “os” directory that contained the initial release version, with all updates in “updates” (and older releases in “vault”).
this is currently an open issue for Peridot (the build system which is used for Rocky Linux 9):
So, the packages are actually still available in Peridots internal repos, but only accessable by directly accessing the files, which means finding them is a matter of a SQL query,
this should of course change in the future
For that there is apparently a solution. dnf looks (and you probably did browse) into 9.0/BaseOS/x86_64/os/Packages
Browse to 9.0/BaseOS/x86_64/kickstart/Packages
That, AFAIK, is the initial point release.
In CentOS 7 the initial point release content was in base and updates were dropped into updates.
In el8 and el9 ${repoid}/${arch}/os and ${repoid}/${arch}/kickstart start identical, and updates are dropped into */os
(“Drop” as in replace, rather than add, currently in Rocky.)
I would also suggest to build your kernel module to not be completely tied to kernel version, but rather the general release of that kernel (meaning the -XXX portion). There shouldn’t be a reason to tie your kmod packages to every released kernel version in a point release in any Enterprise Linux version. A rebuild is generally necessary when a new point release comes out (for example, 9.1 and thus new kernel release), but for 6 months, you shouldn’t have to unless the driver itself has an update.
For example, if you build a package for the module for 4.18.0-425.3.1.el8, that same kmod should work on 4.18.0-425.10.1.el8_7 when it comes out. And then when 4.18.0-5XX.el8 comes around, you rebuild the driver against that and you shouldn’t have to build again unless the driver has an update.
I would check out this elrepo example. This would eliminate the constant rebuilds.
Yes, I probably have to go for something like that with the current situation where I cannot get the correct RPM versions directly. It does complicate build server setup and replication and the build script setup, as the exact versions installed will vary between hosts, and I am trying to achieve reproducible builds and as identical build environments as possible.
This is something Satellite does well. You can specify a package level, and patch all machines to that level, and you can also go back to old package versions.
