Issue #90: Achieve “dnf swap”-equivalent functionality with rpm-ostree - fedora-magazine-newsroom

fedora-magazine-newsroom

#90 Achieve “dnf swap”-equivalent functionality with rpm-ostree

Closed: published 4 months ago by rlengland. Opened 2 years ago by rlengland.

Article Summary: Teach the Fedora Silverblue/Kinoite user how to achieve “dnf swap” functionality, exemplified by replacing nano-default-editor with vim-default-editor

Article Description: Some users might need to achieve something similar to “dnf swap” with rpm-ostree, the one that will be demonstrated will be replacing nano-default-editor with vim-default-editor, but could also be shown with other things such as replacing wireplumber with pipewire-media-session.
All commands will be demonstrated on a Fedora Silverblue 35 VM.
How the article would be laid out:

Introduction

Quick explanation of how dnf swap works, possibly linking to an existing article. Saying that there’s equivalent functionality by how there’s the “–install” and “–uninstall” options on some of rpm-ostree’s commands, which allows doing those tasks along with the current transaction
Demonstrate replacing nano-default-editor with vim-default-editor. Including showing output of “rpm-ostree override remove” on removing nano, “rpm-ostree install” on installing vim and “override remove” and “–install” combined to remove nano and install vim in the same transaction.
Explain a secondary useful usecase where the user might want to run "rpm-ostree upgrade --install --uninstall ", so they can uninstall and install packages in the same transaction. There are actually some reasons the user might run into them:
The main one, just wanting to do remove and install stuff in the same transaction, probably while also doing the system updates, all at once.
Previously on rpm-ostree it was possible that, if you installed a rpm which added a repository, rpm-ostree would keep using the version from the rpm instead of updating to a newer available version from the repository. This was most likely fixed already (ideally I should link to a related issue), but it should be useful to teach users on how to deal with such a case (which is to remove the “local package” and replace with the repo packages).
Depending on the user, they might install rpms which do not add repositories and manage those updates manually, if the user tries to install the rpm of a newer version of the package, rpm-ostree will refuse it. So, ideally they should uninstall the old one and install the new one in the same transaction.

There are a few extra notes:

Apparently replacing nano with vim causes some problems for me sometimes when updating because of dependencies, as far as I noticed it might be related to the state of the mirrors when they receive updates since it’s fixed a few hours later, I should probably mention it on the article.
I am also not quite sure what package to use for the example of manually installed rpms conflicting with older one when installing a newer version, so I will most likely just create a simple rpm myself for that.

https://discussion.fedoraproject.org/t/article-proposal-achieve-dnf-swap-equivalent-fucntionality-with-rpm-ostree/37079

Metadata Update from @rlengland:
- Issue tagged with: article, needs-image

2 years ago

mateusrodcosta commented 2 years ago

Hi, I have been busy those last days so I haven't been able to actually focus on this, but I should be able to start writing this week.

I do have a note about this portion in specific:

Previously on rpm-ostree it was possible that, if you installed a rpm which added a repository, rpm-ostree would keep using the version from the rpm instead of updating to a newer available version from the repository. This was most likely fixed already (ideally I should link to a related issue), but it should be useful to teach users on how to deal with such a case (which is to remove the “local package” and replace with the repo packages).

I could sum up this behavior as "rpm-ostree will always prefer the previously manually installed RPMs (the ones it marks as LocalPackages) over newer versions regardless of whether the new version comes from the repository or is another RPM you are manually installing"

This does make a significant difference, as an example today I decided to upgrade my main machine to Fedora 36 Beta and I had RPMFusion enabled with its repo rpms as LocalPackages and it would refuse to rebase due to the dependencies. However when I ran rpm-ostree upgrade --uninstall rpmfusion-free-release-35-1.noarch --uninstall rpmfusion-nonfree-release-35-1.noarch --install rpmfusion-free-release --install rpmfusion-nonfree-release which would effectively "uninstall" the manually installed version to install one from the repos, then the dependency solving went alright due to rpm-ostree not trying to keep the old versions.

I did ask another Fedora Silverblue user if on their system RPMFusion was correctly upgraded and they just said that they usually ran a reset on rpm-ostree before upgrades.

I do not know if that's intended rpm-ostree behavior or if someone else also got to understand how to deal with this behavior, but I will make a note of this in the article.

mateusrodcosta commented 2 years ago

Hi, I am giving up on this as an article for now and maybe even stopping contributing to Fedora Magazine for a while. I wasn't in a very good mood those last few months so, now that I am, I think I shouldn't hold this as pending anymore.

I believe I should try to join the Docs project instead and, for content such as this along with other stuff, I would do better as adding for the actual documentation pages, like, for example, improving a lot the docs for Silverblue with way more commands rpm-ostree that might be useful for very specific situation some users might hit, along explanations (upstream issues, for example) and all that. I might even branch off for other non-Silverblue-specific stuff.

So, I would suggest canning this for now.

Thanks!

theevilskeleton commented 2 years ago

No problem! I hope you enjoy contributing to Fedora Docs!

Unfortunately I can't change the label to "stalled" or the likes. Another editor will have to do it.

Edited 2 years ago by theevilskeleton

mateusrodcosta commented 4 months ago

I'm planning on restarting work on this now at the beginning of 2024.

rlengland commented 4 months ago

@mateusrodcosta Glad to hear that you'll restart on your article. I've moved it back to the "In progress" category in the Pagure Fedora-Magazine-Newsroom.

Let us know when you have the WordPress preview ready and we'll proceed.

Happy new year and welcome back. :-)

Edited 4 months ago by rlengland

mateusrodcosta commented 4 months ago

Initial draft is done at https://fedoramagazine.org/wp-admin/post.php?post=39590&action=edit

Metadata Update from @rlengland:
- Custom field preview-link adjusted to https://fedoramagazine.org/?p=39590&preview=true&preview_id=39590

4 months ago

mateusrodcosta commented 4 months ago

So, on the article I gave an example of what's the error message if you try to remove nano-default-editor as you don't meet the requirement to have something that provides a default editor.

However I have been thinking on whether it also makes sense to have something about what's the error message if you try to install vim-default-editor without also removing nano-default-editor.

Maybe also it would be interesting to have a comparison from dnf outputs? At least dnf would potentially guide the user to use --allowerasing, which could be good enough advice.