Rpm-ostree: Exclude Packages from an Upgrade Command

When using dnf, I can exclude packages foo, bar, woe from, say an upgrade transaction, like this:

dnf upgrade --exclude foo --exclude bar --exclude woe

Is there a similar syntax for rpm-ostree under Silverblue?

You may wonder what may be the motivation for such a syntax. Here is my current motivation:

I) What could be updated? This:rpm-ostree upgrade --preview

AvailableUpdate:
        Version: 35.20220213.0 (2022-02-13T00:49:17Z)
         Commit: faf747c4006db1d83e696d191a3d8935d5615dacb8125eab345ecc845d1a7ab3
   GPGSignature: 1 signature
                 Signature made Sun 13 Feb 2022 01:49:24 +01 using RSA key ID DB4639719867C58F
                 Good signature from "Fedora <fedora-35-primary@fedoraproject.org>"
  SecAdvisories: FEDORA-2022-cbd155f714  Moderate   webkit2gtk3-2.34.5-1.fc35.x86_64
                 FEDORA-2022-cbd155f714  Moderate   webkit2gtk3-jsc-2.34.5-1.fc35.x86_64
                   CVE-2022-22589 webkit2gtk3: webkitgtk: Processing a maliciously crafted mail message may lead to running arbitrary javascript [fedora-all]
                   https://bugzilla.redhat.com/show_bug.cgi?id=2053180
                   CVE-2022-22590 webkit2gtk3: webkitgtk: Processing maliciously crafted web content may lead to arbitrary code execution [fedora-all]
                   https://bugzilla.redhat.com/show_bug.cgi?id=2053182
                   CVE-2022-22592 webkit2gtk3: webkitgtk: Processing maliciously crafted web content may prevent Content Security Policy from being enforced [fedora-all]
                   https://bugzilla.redhat.com/show_bug.cgi?id=2053186
       Upgraded: cpp 11.2.1-7.fc35 -> 11.2.1-9.fc35
                 distribution-gpg-keys 1.62-1.fc35 -> 1.64-1.fc35
                 gcc 11.2.1-7.fc35 -> 11.2.1-9.fc35
                 gcc-c++ 11.2.1-7.fc35 -> 11.2.1-9.fc35
                 gcc-gdb-plugin 11.2.1-7.fc35 -> 11.2.1-9.fc35
                 kernel 5.16.7-200.fc35 -> 5.16.8-200.fc35
                 kernel-core 5.16.7-200.fc35 -> 5.16.8-200.fc35
                 kernel-devel 5.16.7-200.fc35 -> 5.16.8-200.fc35
                 kernel-modules 5.16.7-200.fc35 -> 5.16.8-200.fc35
                 kernel-modules-extra 5.16.7-200.fc35 -> 5.16.8-200.fc35
                 libgcc 11.2.1-7.fc35 -> 11.2.1-9.fc35
                 libgomp 11.2.1-7.fc35 -> 11.2.1-9.fc35
                 libstdc++ 11.2.1-7.fc35 -> 11.2.1-9.fc35
                 libstdc++-devel 11.2.1-7.fc35 -> 11.2.1-9.fc35
                 libubsan 11.2.1-7.fc35 -> 11.2.1-9.fc35
                 mesa-dri-drivers 21.3.5-1.fc35 -> 21.3.6-1.fc35
                 mesa-filesystem 21.3.5-1.fc35 -> 21.3.6-1.fc35
                 mesa-libEGL 21.3.5-1.fc35 -> 21.3.6-1.fc35
                 mesa-libGL 21.3.5-1.fc35 -> 21.3.6-1.fc35
                 mesa-libgbm 21.3.5-1.fc35 -> 21.3.6-1.fc35
                 mesa-libglapi 21.3.5-1.fc35 -> 21.3.6-1.fc35
                 mesa-libxatracker 21.3.5-1.fc35 -> 21.3.6-1.fc35
                 mesa-vulkan-drivers 21.3.5-1.fc35 -> 21.3.6-1.fc35
                 pango 1.50.3-1.fc35 -> 1.50.4-1.fc35
                 python3-google-api-core 2.4.0-4.fc35 -> 2.5.0-1.fc35
                 webkit2gtk3 2.34.4-2.fc35 -> 2.34.5-1.fc35
                 webkit2gtk3-jsc 2.34.4-2.fc35 -> 2.34.5-1.fc35

II) All right! Here we go: rpm-ostree upgrade

Receiving metadata objects:  ...
Checking out tree ...
Enabled rpm-md repositories: ...
Updating metadata for ...
Importing rpm-md ...
rpm-md repo ...
Resolving dependencies... done

error: Could not depsolve transaction; 1 problem detected:
 Problem: conflicting requests
  - package clang-13.0.0-3.fc35.i686 requires gcc-c++, but none of the providers can be installed
  - package clang-13.0.0-3.fc35.x86_64 requires gcc-c++, but none of the providers can be installed
  - package clang-13.0.0~rc1-1.fc35.i686 requires gcc-c++, but none of the providers can be installed
  - package clang-13.0.0~rc1-1.fc35.x86_64 requires libLLVM-13.so.0()(64bit), but none of the providers can be installed
  - package clang-13.0.0~rc1-1.fc35.x86_64 requires libLLVM-13.so.0(LLVM_13)(64bit), but none of the providers can be installed
  - package gcc-c++-11.2.1-7.fc35.x86_64 requires gcc = 11.2.1-7.fc35, but none of the providers can be installed
  - package gcc-c++-11.2.1-1.fc35.i686 requires gcc = 11.2.1-1.fc35, but none of the providers can be installed
  - package gcc-c++-11.2.1-1.fc35.x86_64 requires gcc = 11.2.1-1.fc35, but none of the providers can be installed
  - cannot install both llvm-libs-13.0.0~rc1-1.fc35.x86_64 and llvm-libs-13.0.0-4.fc35.x86_64
  - cannot install both gcc-11.2.1-7.fc35.x86_64 and gcc-11.2.1-9.fc35.x86_64
  - cannot install both gcc-11.2.1-1.fc35.x86_64 and gcc-11.2.1-9.fc35.x86_64

What a bummer! It seems gcc or dependencies thereof have some issues. It would be nice to be able to carry on with updating the other packages whilst waiting for fixes for the broken dependencies; something akin to

rpm-ostree upgrade --exclude cpp --exclude gcc --exclude gcc-c++ --exclude gcc-gdb-plugin --exclude libgcc --exclude libgomp --exclude libstdc++ --exclude libstdc++-devel

In this specific instance, I would get security fixes for webkit2gtk3 as well as a new kernel without being bottle-necked to some brokenness elsewhere.

A cursory search shows that there is an exclude feature for rpm-ostree compose, but I guess that is useful for server-side stuff. I am not composing anything, I would like to get just some updates.

I see several i686 packages that conflict with the x86_64 updates. Try removing those i686 packages. That will do no harm unless they are dependencies of something else you have installed.

There are no i686 packages installed, I do not know how the dependency solver
ended up with those i686 conflicts. This is what I get by querying the
rpm database:

rpm --query --queryformat "%{NAME} → %{ARCH}\n" --all | grep '686'
    # libertas-sd8686-firmware → noarch

rpm --query --queryformat "%{NAME} → %{ARCH}\n" --all | grep 'i686' | wc -l
    # 0

By the way, I somehow overcame the OP issue by removing clang from the
layered package set. Not only was it responsible for the puzzling conflicts, it also
had no strong reason of being globally available: it can happily live in a toolbox.

Still, I would appreciate pointers of how to exclude specific packages from an
rpm-ostree upgrade transaction.

You should provide the output of rpm-ostree status when you have update issues.

There is currently no easy way to exclude a package from an upgrade but you could potentially override it to a fixed version and then do the update.

There is currently no easy way to exclude a package from an upgrade

ACK.

but you could potentially override it to a fixed version and then do the update.

What I did was

  1. uninstall the package which was making the whole transaction fail
  2. upgrade the system and reboot
  3. re-install the just-removed package.

However, such a process does not feel like a great user experience, especially since I had to repeat it one day later, this time with another package—util-linux-user which was conflictiing with util-linux.

I don’t know what is going on with these conflicts between packages from the base image and layered ones. Here is the output that you asked for: rpm-ostree status --booted

State: idle
BootedDeployment:
● fedora:fedora/35/x86_64/silverblue
                   Version: 35.20220217.0 (2022-02-17T02:42:26Z)
                BaseCommit: 032a54c9c6d3d0aa348ae5a43e2f69465a63a96db84e6aaa4984ab55c06c15e7
              GPGSignature: Valid signature by 787EA6AE1147EEE56C40B30CDB4639719867C58F
      ReplacedBasePackages: xkeyboard-config 2.33-2.fc35 -> 2.33-3.fc35
           LayeredPackages: bat below blivet-gui deja-dup exa fd-find fish ncdu pcre2-tools ripgrep strace tor torsocks
             LocalPackages: rpmfusion-free-release-35-1.noarch rpmfusion-nonfree-release-35-1.noarch

Summary of the conflicts that I had to work around so far:

Base Image Package Layered Package
gcc clang
util-linux util-linux-user[1]

PS. For the ReplacedBasePackages bit, maybe you could provide insights about the idiomatic way of solving ask.fpo.org/t/19862 (I am not allowed to create what this interface believes is a second URL).


  1. There seems to be no need to install this one any more; since after the upgrade, rpm-ostree install util-linux-user spits out “error: Package/capability ‘util-linux-user’ is already requested”. Alas, for instance the binary chsh—provided by that supposedly “already requested” package—is nowhere to be found: command --search chsh returns an empty string. ↩︎

With rpm-ostree, we can only guarantee that updates between images will work without interaction. Once you overlay packages, you are on your own like classic dnf based Fedora systems to figure out the conflicts.

As a side note, I recommend to not change the default shell on rpm-ostree based systems and instead use the default shell config to switch to the one you want to use instead and gracefully fallback to the default if it does not exist (like when you do a full system reset).

1 Like

uhm, I have a similar issue on Kinoite beta and would like to just not install that package, even more as it seems to be downloaded with an update

There are problems with kdepim-runtime and libakonadi, but kdpim* is not even installed.