Open fbruetting opened 5 years ago
Unfortunately, the way --preview
works, there's a bit of "guessing" when it comes to layered packages. It will alert for changes if any layered packages have newer versions in the fetched metadata, but it doesn't actually do any depsolving.
So e.g. if you have pkg-a
installed which pulls in pkg-b
at a specific version, a newer version of pkg-b
will show up as an available update regardless of whether it'd actually be pulled in (e.g. if pkg-a
has a tight binding on the version of pkg-b
, it won't).
We could resolve dependencies in the case where we already have the base layer (as is the case in your output, since there isn't a new OSTree commit available), but the problem would still exist if we don't.
Seems to be a duplicate of #680.
I'm going to reopen this one since it's not exactly the same as #680. That issue is about diff output formatting. This issue is about the discrepancy caused by the guessing rpm-ostree does.
Another real-life example of this in https://bugzilla.redhat.com/show_bug.cgi?id=1705494.
I think we should push to automatic staged updates by default and not care too much about --preview
.
Yeah, I don't want to spend too long trying to make --preview
perfect. Will think on this to see if there are any lightweight heuristics we could do.
I think we should push to automatic staged updates by default
That'd help, though (without going too much into the weeds of #247) I suspect check
to still be popular for a lot of use cases.
I have the same problem:
rpm-ostree upgrade ⠤ Receiving metadata objects: 0/(estimating) -/s 0 bytes... Receiving metadata objects: 0/(estimating) -/s 0 bytes... done Checking out tree b1e920e... done Enabled rpm-md repositories: fedora updates rpmfusion-free google-chrome rpmfusion-nonfree-updates rpmfusion-nonfree rpmfusion-free-updates rpm-md repo 'fedora' (cached); generated: 2019-10-23T22:52:47Z rpm-md repo 'updates' (cached); generated: 2020-03-14T00:03:21Z rpm-md repo 'rpmfusion-free' (cached); generated: 2019-10-22T10:21:36Z rpm-md repo 'google-chrome' (cached); generated: 2020-03-12T16:55:01Z rpm-md repo 'rpmfusion-nonfree-updates' (cached); generated: 2020-03-13T11:20:29Z rpm-md repo 'rpmfusion-nonfree' (cached); generated: 2019-10-22T10:43:47Z rpm-md repo 'rpmfusion-free-updates' (cached); generated: 2020-03-13T10:46:34Z Importing rpm-md... done Resolving dependencies... done No upgrade available.
rpm-ostree upgrade --preview 1 metadata, 0 content objects fetched; 569 B transferred in 3 seconds Enabled rpm-md repositories: fedora updates rpmfusion-free google-chrome rpmfusion-nonfree-updates rpmfusion-nonfree rpmfusion-free-updates Updating metadata for 'fedora'... done rpm-md repo 'fedora'; generated: 2019-10-23T22:52:47Z Updating metadata for 'updates'... done rpm-md repo 'updates'; generated: 2020-03-14T00:03:21Z Updating metadata for 'rpmfusion-free'... done rpm-md repo 'rpmfusion-free'; generated: 2019-10-22T10:21:36Z Updating metadata for 'google-chrome'... done rpm-md repo 'google-chrome'; generated: 2020-03-12T16:55:01Z Updating metadata for 'rpmfusion-nonfree-updates'... done rpm-md repo 'rpmfusion-nonfree-updates'; generated: 2020-03-13T11:20:29Z Updating metadata for 'rpmfusion-nonfree'... done rpm-md repo 'rpmfusion-nonfree'; generated: 2019-10-22T10:43:47Z Updating metadata for 'rpmfusion-free-updates'... done rpm-md repo 'rpmfusion-free-updates'; generated: 2020-03-13T10:46:34Z Importing rpm-md... done AvailableUpdate: Upgraded: google-chrome-stable 80.0.3987.116-1 -> 80.0.3987.132-1 rpmfusion-nonfree-release 31-1 -> 31-2
As seen here this information is used by gnome software to show to the user that available updates exist. However when you hit "Restart and update", the PC reboots but the same updates are still listed.
It seems the root cause for all the problems is the following https://github.com/coreos/rpm-ostree/issues/1978
Host system details
Expected vs actual behavior
See the following output: With
--preview
it wants to upgrademesa-libOpenCL
, while without, it doesn’t find anything up upgrade. That’s weird.