https://bugs.kde.org/show_bug.cgi?id=507827

--- Comment #2 from [email protected] ---
(In reply to TraceyC from comment #1)
> Thanks for the feature request! There are two distinct requests being made.
> To summarize:
> 
> 1. Wanting Discover to still show updates after they have been downloaded
> 2. Wanting Discover to show what was just downloaded after updating manually
> while the system still needs a restart.
> 
> Can you clarify something for case #1? In the attached screenshot, in the
> terminal, I see you had run `sudo dnf update`. That performed the actual
> update, rather than just checking for updates.
> 
> `dnf check-update` is what you want to run to check for updates without
> installing them. After running that, and checking Discover, the pending
> updates are still listed. If you do this and refresh Discover, it will
> indeed show no updates available, because they have already been installed.
> Can you clarify if this matches what you did? If not, can you walk us
> through what you did exactly, step by step? I'd like to understand how to
> get to the state where updates have been downloaded but aren't showing up in
> Discover - updates.
>  
> I tested this with Discover set to auto-update on Fedora 42 Plasma 6.4.3
> 122 updates shown in Discover before and after performing those steps
> 
> 1. I ran `dnf upgrade --downloadonly` and then `dnf check-upgrade` which
> still showed the list of packages to be installed.
> 2. I refreshed the update list in Discover, it still showed the same amount
> of updates available
> 
> For case #2 where you're manually triggering updates, wouldn't the simple
> solution be to check the update list before triggering the update? Can you
> help us understand what would justify the work needed to make an additional
> section, when there's an existing way to get this information?
> 
> Thanks!

#1
I typically check with sudo dnf update for convenience, as it is the first
command that comes to mind for that and I can choose whether to actually do
anything after the command is run, since i didn't run sudo dnf update -y.
Because of this, this command I ran didn't do anything but check for updates
because I had not yet told it to (I just closed the terminal after and did the
updates I was talking about through discover). I cannot test again right now
because I don't have any updates available at the moment. here's what I did:

1. open Discover
2. refresh discover to make sure it wasn't missing anything (it wasn't)
3. open Konsole (no moving of anything neccesary bc tiling)
4. run sudo dnf update
5. scroll to the top to show the command that had been run
6. take screenshot (the one I attached originally)
7. close Konsole and Discover
8. restart to apply updates that Discover had downloaded

note that no input was given to Konsole after running dnf update, so it was
waiting for a y/n answer to whether it should update and never changed
anything. also note that discover had already automatically downloaded all
available updates. I think this second point may be the difference because the
updates were still being shown on your system, meaning discover had likely not
downloaded them yet.


#2
generally speaking, yes. however sometimes you run into a situation where you
were about to update because there was no reason not to, and then one appears.
this may leave you with updates downloaded but something to do that updating
would prevent or delay. to give an example from my typical use case for my
computer, a friend texting to get on a game. It would be useful in a situation
like that to be able to look over the stuff that has updates after it's been
downloaded and see if it's worth bothering to restart now. for example, a
driver update would be worth going ahead and restarting to apply the update in
that case. something like an app installed via rpm or similar format wouldn't
be. Yeah you'd probably be fine either way, but it would be nice to be able to
check

as a separate point related to #2, it would also help avoid hiding what the
computer is doing from the user. I know that info is not being hidden
intentionally but it **is** being hidden. This is probably something that's
best avoided, even if it's due to principle and not an actual problem

-- 
You are receiving this mail because:
You are watching all bug changes.

Reply via email to