Better handling of `error: Base packages would be removed`

fbruetting commented 5 years ago

Host system details

● ostree://fedora-workstation:fedora/29/x86_64/silverblue
                   Version: 29.20181127.0 (2018-11-27T01:07:31Z)
                BaseCommit: 16cc069dd42bd0cf4fa6244c0c1940ab8fe0fdc5ab1379717913fff46c553121
              GPGSignature: Valid signature by 5A03B4DD8254ECA02FDA1637A20AA56B429476B4
       RemovedBasePackages: gnome-shell-extension-alternate-tab-3.30.1-1.fc29.noarch
                            gnome-shell-extension-places-menu-3.30.1-1.fc29.noarch
                            gnome-shell-extension-window-list-3.30.1-1.fc29.noarch
                            gnome-classic-session-3.30.1-1.fc29.noarch
                            gnome-shell-extension-apps-menu-3.30.1-1.fc29.noarch
                            gnome-terminal-3.30.2-1.fc29.x86_64
                            gnome-shell-extension-launch-new-instance-3.30.1-1.fc29.noarch
           LayeredPackages: adapta-gtk-theme android-tools baobab bat cheese
                            chrome-gnome-shell chromium dconf-editor dnf easytag exa
                            exfat-utils fd-find ffmpeg file-roller file-roller-nautilus git
                            gnome-encfs-manager gnome-logs gnome-tweaks gnome-usage gpick
                            hack-fonts htop iftop julia linux-libertine-biolinum-fonts
                            linux-libertine-fonts mosh neovim powerline-go pv
                            python3-matplotlib ripgrep task tilix tilix-nautilus tmux tokei
                            xenlism-wildfire xenlism-wildfire-midnight youtube-dl zsh
             LocalPackages: rpmfusion-nonfree-release-29-0.5.noarch
                            rpmfusion-free-release-29-0.5.noarch

Expected vs actual behavior

I sometimes cannot update my system, because of one of my modifications, like shown below:

# sudo rpm-ostree upgrade
Importing metadata [=============] 100%               Resolving dependencies... failede
error: Base packages would be removed: gnome-terminal-nautilus-3.30.2-1.fc29.x86_64

The thing here is, that I neither added nor removed gnome-terminal-nautilus, which is why I was a bit surprised here at first. That turned out to be an issue of gnome-terminal (which I deleted from base), because rpm-ostree wanted to install a dependency of that deleted package.

After resetting gnome-terminal I could update my system and delete both gnome-terminal-nautilus and gnome-terminal, to get the desired system state.

Expected:

1) When I’m not able to upgrade, it would be good if the cause of the error could be shown. I.e. the packages I layered or removed from base, so that we don’t need to guess and play through several scenarios of removing or resetting packages and trying if that solved the issue.

2) Specifically to this issue, this error: Base packages would be removed was no error at all, as when I intentionally delete a package from base, I of course also want to delete all dependencies, too. So I expected rpm-ostree to do this implicitly (as long as the dependencies aren’t specifically requested to be in base, of course).

Notes

Particularly, those problems often arise because of dnf being layered (⇒ different libdnf versions), maybe this could be better synchronized, too?
Also note that “failede” in the second line of the output. Either this line was not completely overridden, or there is some spelling mistake.

jlebon commented 5 years ago

This is the same issue as what you mentioned in #1613, right? See comment on that here: https://github.com/projectatomic/rpm-ostree/issues/1613#issuecomment-429870404.

fbruetting commented 5 years ago

Yes, but not only this.

The first issue here, was that the rpm-ostree error displays the package which led to the conflict at the end of the chain. But as you can see in my example, this might be below the level of what users did and thus has to be debugged every time, because it may not be obvious which modification led to this. Instead it would be good if some sort of “stacktrace” could be done up all layers until the user modification. Then users would immediately see the root of an issue. Here, I could imagine something like “There’s issue X with gnome-terminal-nautilus, because it’s a dependency of gnome-terminal, which in turn was modified by being removed from base” (but of course with a more precise description than my silly line here).

The second issue is about the same as what I mentioned in the other issue, where I asked if dependencies of from-base-removed packages could also get removed. I think this dependency removal would make sense, because those packages wouldn’t be in base if the parent package wasn’t pulled in the first place. If dependencies are explicitly required in base, I would think that those should rather also be explicitly listed in the list of all base packages, or? I my example, I see no reason for the dependencies of gnome-classic-session to remain on the system. And if something breaks, I am very pleased that I run such a splendid OSTree system, which I could easily reset via reboot! :D

coreos / rpm-ostree