Hi,
I’m currently fine-tuning my DNF Automatic configuration on my Rocky Linux 8 servers.
How can I manually downgrade one or a handful of packages ? Ideally without wrecking my system ? And how would I go about that ? This would allow me to test DNF Automatic without having to wait for new available updates.
Cheers,
Niki
This link to a recent discussion on downgrading may be useful:
Downgrading
Erm… maybe anybody has a simple one-liner to downgrade a single package (like tzdata or similar) only for testing purposes and without having to jump through burning loops ? Would be much appreciated.
the dnf downgrade option should work for simple cases
dnf downgrade tzdata
Here’s what I get:
# dnf downgrade tzdata
Package tzdata of lowest version already installed, cannot downgrade it.
Dependencies resolved.
Nothing to do.
Complete!
Same result with pretty much any other package.
Looks like tzdata has not been updated since since upgrading to Rocky 8.9?
Can’t downgrade to a previous 8.8 version.
I’ve tested with firefox and that can be downgraded.
You cannot, by default, downgrade to versions of packages from any previous release. This is explained in our version policy.
When a new minor release arrives, all previous updates/versions are not carried over.
If you absolutely need to downgrade, you will need to setup a way to interact with the vault. You can use --repofrompath to try to do this, but ymmv.
In Fedora you can add the following repo
dnf install fedora-repos-archive
this allows the downgrade, or reversal of any single package or even a whole dnf update.
whole updates are done with dnf history.
I think all RPM distributions should offer this, its not that hard to do, just archive all prior versions
of packages to the archive repo before replacing the current main update repo with new.
why kill off one of the best features of rpm based distributions by not offering this.
people often find that an rpm package update has introduced a conflict or issue with there single workstation, and want to prove its the update that caused it, and then file a bug report.
It may of course be a limitation in storage resources at rockys mirrors that is the limiting factor.
of course if the distribution ie rocky in this case does not offer this, it is possible to create your own
repo localy on your network, that prior to reposync , copies all old versions to an archive repo , and runs createrpo on it, then make all your servers and workstations use the local repos instead of pulling from rockys repos, this will also lighten the load on the mirrors, essential to do if you are a company with many rocky instances.
regards peter
Thanks for all your input, guys. I found a very simple solution to my problem. Remember that the main objective here was to test DNF Automatic, so I needed to downgrade any random package from my server installation to create the need for an update. I simply chose a package from a third-party repository whose policy it is to keep older versions, and I chose Lynis for this:
# dnf downgrade lynis
This installed version 3.0.8 instead of 3.0.9, and I could happily test my automatic upgrade script.
Problem solved. Cheers !
Niki
This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.