F41 to F42 fails with golang conflicts

Ask Fedora
, ,
1

I updated F41 to F42 via the Gnome GUI. It fails with conflicts between golang packages.

Should I remove golang entirely and then retry dnf, or does Fedora need it?

Packages affected:

golang-github-cespare-xxhash-devel-2.1.2-15.fc42.noarch
golang-github-cespare-xxhash2-devel-2.3.0-2.fc42.noarch

golang-gopkg-readline-1-devel-1.4-24.20180628git2972be2.fc42.noarch
golang-github-chzyer-readline-devel-1.5.1-2.fc42.noarch

Full error message:

Transaction failed: Rpm transaction failed.
 - file /usr/share/gocode/src/github.com/chzyer/readline from install of golang-github-chzyer-readline-devel-1.5.1-2.fc42.noarch conflicts with file from package compat-golang-github-chzyer-readline-devel-1.4-22.20180628git2972be2.fc41.noarch
 - file /usr/share/gocode/src/github.com/cespare/xxhash/v2 from install of golang-github-cespare-xxhash2-devel-2.3.0-2.fc42.noarch conflicts with file from package compat-golang-github-cespare-xxhash-2-devel-2.1.2-13.fc41.noarch
 - file /usr/share/gocode/src/github.com/cespare/xxhash/.goipath conflicts between attempted installs of golang-github-cespare-xxhash-devel-2.1.2-15.fc42.noarch and golang-github-cespare-xxhash2-devel-2.3.0-2.fc42.noarch
 - file /usr/share/gocode/src/github.com/cespare/xxhash/bench_test.go conflicts between attempted installs of golang-github-cespare-xxhash-devel-2.1.2-15.fc42.noarch and golang-github-cespare-xxhash2-devel-2.3.0-2.fc42.noarch
 - file /usr/share/gocode/src/github.com/cespare/xxhash/xxhash.go conflicts between attempted installs of golang-github-cespare-xxhash-devel-2.1.2-15.fc42.noarch and golang-github-cespare-xxhash2-devel-2.3.0-2.fc42.noarch
 - file /usr/share/gocode/src/github.com/cespare/xxhash/xxhash_amd64.s conflicts between attempted installs of golang-github-cespare-xxhash-devel-2.1.2-15.fc42.noarch and golang-github-cespare-xxhash2-devel-2.3.0-2.fc42.noarch
 - file /usr/share/gocode/src/github.com/cespare/xxhash/xxhash_other.go conflicts between attempted installs of golang-github-cespare-xxhash-devel-2.1.2-15.fc42.noarch and golang-github-cespare-xxhash2-devel-2.3.0-2.fc42.noarch
 - file /usr/share/gocode/src/github.com/cespare/xxhash/xxhash_safe.go conflicts between attempted installs of golang-github-cespare-xxhash-devel-2.1.2-15.fc42.noarch and golang-github-cespare-xxhash2-devel-2.3.0-2.fc42.noarch
 - file /usr/share/gocode/src/github.com/cespare/xxhash/xxhash_test.go conflicts between attempted installs of golang-github-cespare-xxhash-devel-2.1.2-15.fc42.noarch and golang-github-cespare-xxhash2-devel-2.3.0-2.fc42.noarch
 - file /usr/share/gocode/src/github.com/cespare/xxhash/xxhash_unsafe.go conflicts between attempted installs of golang-github-cespare-xxhash-devel-2.1.2-15.fc42.noarch and golang-github-cespare-xxhash2-devel-2.3.0-2.fc42.noarch
 - file /usr/share/gocode/src/github.com/cespare/xxhash/xxhash_unsafe_test.go conflicts between attempted installs of golang-github-cespare-xxhash-devel-2.1.2-15.fc42.noarch and golang-github-cespare-xxhash2-devel-2.3.0-2.fc42.noarch
 - file /usr/share/gocode/src/gopkg.in/readline.v1/.goipath conflicts between attempted installs of golang-gopkg-readline-1-devel-1.4-24.20180628git2972be2.fc42.noarch and golang-github-chzyer-readline-devel-1.5.1-2.fc42.noarch
 - file /usr/share/gocode/src/gopkg.in/readline.v1/operation.go conflicts between attempted installs of golang-gopkg-readline-1-devel-1.4-24.20180628git2972be2.fc42.noarch and golang-github-chzyer-readline-devel-1.5.1-2.fc42.noarch
 - file /usr/share/gocode/src/gopkg.in/readline.v1/readline.go conflicts between attempted installs of golang-gopkg-readline-1-devel-1.4-24.20180628git2972be2.fc42.noarch and golang-github-chzyer-readline-devel-1.5.1-2.fc42.noarch
 - file /usr/share/gocode/src/gopkg.in/readline.v1/runebuf.go conflicts between attempted installs of golang-gopkg-readline-1-devel-1.4-24.20180628git2972be2.fc42.noarch and golang-github-chzyer-readline-devel-1.5.1-2.fc42.noarch
 - file /usr/share/gocode/src/gopkg.in/readline.v1/term.go conflicts between attempted installs of golang-gopkg-readline-1-devel-1.4-24.20180628git2972be2.fc42.noarch and golang-github-chzyer-readline-devel-1.5.1-2.fc42.noarch
 - file /usr/share/gocode/src/gopkg.in/readline.v1/terminal.go conflicts between attempted installs of golang-gopkg-readline-1-devel-1.4-24.20180628git2972be2.fc42.noarch and golang-github-chzyer-readline-devel-1.5.1-2.fc42.noarch
 - file /usr/share/gocode/src/gopkg.in/readline.v1/utils.go conflicts between attempted installs of golang-gopkg-readline-1-devel-1.4-24.20180628git2972be2.fc42.noarch and golang-github-chzyer-readline-devel-1.5.1-2.fc42.noarch
 - file /usr/share/gocode/src/gopkg.in/readline.v1/utils_unix.go conflicts between attempted installs of golang-gopkg-readline-1-devel-1.4-24.20180628git2972be2.fc42.noarch and golang-github-chzyer-readline-devel-1.5.1-2.fc42.noarch
3

I am still learning to use Linux. How can one do this?

4

In my case, it was fairly simple:

sudo dnf remove golang*

After that was done, since the previous upgrade attempt had stopped in the midst,

sudo dnf clean packages
sudo dnf clean all
sudo dnf system-upgrade reboot
sudo dnf upgrade --refresh

A bit of belt-and-suspenders approach, but it worked.

5

Thanks!

I somehow put the solution flag on my post instead of yours. Sorry about that!

6

Thanks for responding. Would the same command work on Silverblue?

7

For questions about Fedora Silverblue, please create a new topic at #silverblue topics with all the details and the output of the rpm-ostree status command as pre-formatted text.

8

I thought I was able to do it with a little more nuance. It looks to me like there are only two packages that are genrating these messages. golang-github-chzyer-readline-devel and golang-github-cespare-xxhash-devel. Then I removed them and it uninstalled all but one golang package.

If I’m not mistaken, this could be eliminated by configuring the RPMs in question to provide the old package in addition to obsoleting it. There might be a little more magic than this needed; I’m a developer at work, but I’m not one of the ones who manages the RPMs. I just seem to recall them saying that this was what they did to fix this issue with our own (in-house) code.