No incremental update using DNF?

I looked at DNF manual and it doesn’t look like there’s a way to do incremental updates. What I mean by incremental is: to update each package with updates available only one iteration up and perhaps only if it’s not the latest update for that package. I know if you are not on Rawhide you are getting updates that are more tested and you also have an ability to roll back an entire DNF update transaction. It still feels risque to just hop to the latest version of packages as if you are on a rolling release almost.

No, that’s not possible.
Note: Only the latest package provides compatibility and security.

But you can stay one release behind the most recent one. For example, F38 will be supported until after release of f40.

3 Likes

Thanks. I guess there are also compatibility and security issues. Oh, well. Wishful thinking.

Do you mean to go from xyz-1.0-1 to xyz-1.0-2, i.e., the next release? Or from xyz-1.0-… to xyz-1.1-…, i.e., the next version?

dnf will update to whatever is available. We package maintainers don’t always only update the release once—we may bundle a bunch of packaging and other fixes into multiple releases. Next, we also don’t always only update to the next version of the software—we may skip a new version if it doesn’t seem beneficial to push it to users, or simply because we don’t have the time.

On the rolling back—one can’t roll back to just any package version-release. We only hold two versions of packages in the repos—the version at the time of a Fedora release, i.e., the packages in the fedora repo when F39 was released, and the latest version in the updates repo (if any, and also in the updates-testing repo, which will replace the one in the updates repo if it passes QA). So, if one updates twice, and then tries to roll back, they can only go back to the initial version from the fedora repo, not the intermediate version that they have updated to before.

3 Likes

It can be from xyz-1.0-1 to xyz-1.0-2 or from xyz-1.0-… to xyz-1.1… The issue is psychological resistance against updating often because you don’t want to risk breaking things which then results in psychological resistance from updating rarely because you don’t want to risk updating a lot of things that accumulated at once and risking breaking things. And there’s no way to structure updates so you can at least have sort of a way to keep watch and test the updates instead of having a giant deluge of updates at a time?
Is there a way to update packages by groups? Or group updates in any way? This would help for rawhide people too maybe? Because they could update in modular fashion and know what they updated kind of to watch for bugs? And in general some people may want to never update parts of OS, ie network related or something like that.

Be aware that updates in Fedora follow the policy:

1 Like

Fedora tried for some time with using a modular approach to software and that fizzled. With F39 modular was totally removed from the system.

Theoretically a user could provide themselves a means of downloading and archiving every individual package version released, but that would require a bit of admin and a lot of storage to retain the packages as the updates are released. A self-controlled repo would be needed. Not exactly a mirror, since that would contain only the copies available from updates, but a full archive as the updated packages are released.

I’m not sure I understand. Can’t packages be tagged with labels? So then if you do dnf update --type=network, for example, only network-related packages and their dependencies could get updated?
EDIT: And then just have a feast of labels so you can slice and dice package updates however you want? (one package can fall into many categories)

There are lots of ways of doing things.

The only way I know to be able to keep incremental versions of packages installed would be to create a local archive as the packages are updated so the older replaced version was available for a rollback.

Grouping packages is a different issue and fedora already does groups. dnf group list will show many of them.

If you already know what you like to update, you can run DNF with the package name(s) or wildcards, e.g. dnf upgrade NetworkManager*. Required dependencies for the selected upgraded package(s) will be upgraded alongside with them.

Instead of targeting specific packages for upgrade, you can also turn it around and exclude packages you would like to keep in the version you are currently using, e.g. dnf upgrade --exclude gstreamer1. This will upgrade everything available minus the packages (and their parents depending on it). Multiple --exclude can be given at a single command line to exclude several package name patterns.

In essence what I am trying to say is that without making DNF more complex, the functionality you seek is already supported, just in another way than you had perceived.

I believe the closest that you can find on Fedora is this:

You can specify that DNF should only install packages marked as bugfix or security update. But I can’t guarantee how well it will work.