Repository navigation
Cannot update on Fedora 30 #498
Description
Describe the bug
I'm guessing that Fedora sees the latest release as a new piece of software and not an upgrade to the previously-installed version.
❯ gh --version
gh version 0.5.4 (2020-02-04)
https://github.com/cli/cli/releases/tag/v0.5.4
(BTW, my shell is telling me that gh --version is not exiting with 0, not sure why not...)
Steps to reproduce the behavior
- Download latest RPM:
❯ wget https://github.com/cli/cli/releases/download/v0.5.5/gh_0.5.5_linux_386.rpm
--2020-02-18 16:35:31-- https://github.com/cli/cli/releases/download/v0.5.5/gh_0.5.5_linux_386.rpm
Resolving github.com (github.com)... 140.82.114.3
Connecting to github.com (github.com)|140.82.114.3|:443... connected.
HTTP request sent, awaiting response... 302 Found
..........................
HTTP request sent, awaiting response... 200 OK
Length: 4623126 (4.4M) [application/octet-stream]
Saving to: ‘gh_0.5.5_linux_386.rpm’
gh_0.5.5_linux_386.rpm 100%[=========================================================================================================================>] 4.41M 8.59MB/s in 0.5s
2020-02-18 16:35:38 (8.59 MB/s) - ‘gh_0.5.5_linux_386.rpm’ saved [4623126/4623126]
- Attempt to install it:
❯ sudo dnf install ./gh_0.5.5_linux_386.rpm
[sudo] password for alex:
Last metadata expiration check: 0:05:42 ago on Tue 18 Feb 2020 04:30:14 PM CST.
Dependencies resolved.
============================
Package Architecture Version Repository Size
============================
Installing:
gh i386 0.5.5-1 @commandline 4.4 M
Transaction Summary
============================
Install 1 Package
Total size: 4.4 M
Installed size: 11 M
Is this ok [y/N]: y
Downloading Packages:
Running transaction check
Transaction check succeeded.
Running transaction test
Error: Transaction test error:
file /usr/local/bin/gh from install of gh-0:0.5.5-1.i386 conflicts with file from package gh-0:0.5.4-1.x86_64
Expected vs actual behavior
Usually when upgrading packages, even those not in the package manager, dnf lists the new package as "Upgrading:", instead of "Installing:" Also, usually it succeeds.
System Information
❯ cat /etc/os-release
NAME=Fedora
VERSION="30 (Workstation Edition)"
Activity
mislav commentedon Feb 19, 2020
Thank you for reporting!
Does
dnf upgrade <file>work in this case? Should we amend the installation docs?alexfornuto commentedon Feb 19, 2020
@mislav
dnf upgradedoesn't take arguments, it looks for updates to software managed by version control. I don't know what the fix is, having never maintained a dnf package before, but I would guess something needs to change that letsdnfknow that these packages are different versions of the same thing.When I said dnf shows the package as "Upgrading", I was referring to the output of
dnf install ./file. For example:In order to get myself to the latest version of
gh, I can uninstall the old version and install the new one, but I'm worried I'll have to generate new keys and lose any other settings saved by the current version.mislav commentedon Feb 19, 2020
I see. GitHub CLI stores its settings under
~/.config/gh/. I don't think uninstalling the package will remove that directory, since it has no knowledge of it, so I think it's safe to uninstall+reinstall. Although, I wish there was a smoother upgrade path.Let us know if you find it!
alexfornuto commentedon Feb 19, 2020
Thanks @mislav. I've successfully uninstalled/upgraded without loss of auth. I'd be happy to contribute these "upgrade" instructions to your docs, though I'd hope it would only be temporary.
mislav commentedon Feb 19, 2020
Please do!
mwichmann commentedon Feb 28, 2020
FWIW, I just tried upgrading to the 0.5.7 with
dnf installand it didn't exhibit the behavior described above. So it seems things have gotten better.alexfornuto commentedon Feb 28, 2020
I tried upgrading from
0.5.5to0.5.7and got the same behavior as detailed here, but hopefully the next release will replicate the behavior @mwichmann found, and we can close this without me having to honor my offer to update your docs.mislav commentedon Mar 6, 2020
@alexfornuto Now that 0.6.x is out, could you try upgrading again?
alexfornuto commentedon Mar 6, 2020
Yes, I could. And I did. Upgrading now works as expected. Blast fax kudos all around!
mavit commentedon Mar 7, 2020
I think what happened here was that
dnfdidn't know that you wanted the newer i386 package to replace the older x86_64 package, rather than to be installed in parallel.alexfornuto commentedon Mar 8, 2020
.....yup. That was the 386 package. I'll go flog myself now.
fix(agent): prevent JSON serialization errors with non-serializable d…