#1

I’m trying to test out an update to see if it fixes an issue I’m encountering (and then can give the update karma). However, I’m not sure how to install just one update (and its dependencies) from updates-testing using rpm-ostree (or any other approach on Fedora Silverblue).

What’s the correct way to test RPM/Yum/DNF updates? Can we add it to the instructions for testing updates for karma?

2 Likes
#2

Have you tried with: rpm-ostree override replace <package>?

#3

Yeah, that’s the right way to do this, but we should really ship a more ergonomic wrapper that knows about koji/bodhi.

Although keep in mind, philosphically: since we ship the updates as a unit, you kind of want to test things as a unit…i.e. you want to rebase to the updates-testing ref. And we really want tests that run on the tree before it ships…which gets into a huge tension in the whole system.

#4

A thought just occurred to me that might help with this. Would it be to set up a Silverblue container similar to the Fedora Workstation containers that toolbox creates? That way we can rebase those to updates-testing to test packages rather than rebasing our host OS? I know you could always rebase back to standard Silverblue, but its just kind of a pain. Plus it has the added benefit of making it easier to test packages against the base image without having to factor in any other packages the host OS has layered on.

#5

It would be difficult to test this fix using a toolbox (AFAIK), as it fixes a certain NetworkManager Wi-Fi configuration. Many other updates have similar impacts on the base desktop.

I would also be reluctant to switch entirely to updates-testing (even briefly), as I wouldn’t be able to know whether any regressions were from this update versus others that are currently in testing.

In terms of rpm-ostree override replace <package>, exactly what string should I use for <package>? Can I have an example for particular update I’m trying to test? I’m sure I can adapt that example to the general case.

#6

Also, once I’ve completed running rpm-ostree override replace, I assume that pinning should be removed once the update completes testing (lest I prevent future updates from reaching my computer). I assume the override appears in rpm-ostree status, but is there a recommended way to undo an override once completed? Better yet, is it possible to automatically discard the override once it’s no longer necessary?

#7

Have a look at this (there is an example and it also explains how to reset the override): https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux_atomic_host/7/html/installation_and_configuration_guide/managing_atomic_hosts#overriding_an_existing_rpm_package

1 Like
#8

If rpm-ostree override replace <package> expects <package> to be a path to an RPM, that makes testing updates to systems like NetworkManager difficult because of the multitude of RPMs involved, all of which get updated with each SRPM update. I expect I would need to discover which NM components are installed to my system, download the corresponding replacement RPMs, attempt to install them as an override, and work through any recursive dependencies that may also require updates to resolve the transaction. Then, I’d need to put a note on my calendar to check back in a week or two to see if I can reset the override.

I feel like there should be a more straightforward method for testing updates for karma.

2 Likes
#9

Indeed. Where would be the proper place to notify this so it gets eventually fixed?

1 Like
#10

Is this not a suitable use case for enabling the modularity repo?

#11

Is this not a suitable use case for enabling the modularity repo?

I don’t see how modularity repos would help here. Most of the packages being tested aren’t modular.