#107 Reconsider updates policy
Opened 2 years ago by catanzaro. Modified 19 days ago

I'm getting tired of being prompted by GNOME Software to install updates every day after turning on my computer.

Some thoughts:

  • We should prompt to install updates when shutting down the computer, but this is broken.
  • We shouldn't prompt to install updates first thing in the morning.
  • If we're going to prompt the ser to install updates, it should only come after a few days of not having installed the updates with the power-off dialog.
  • We should check for updates less-frequently, once every week or so. Current logic is to check daily and notify daily if there is a security update, or weekly otherwise. But it seems there are too many security updates. I would change this to always check weekly at first, maybe with an eye towards even less-frequent checks.
  • By checking for updates less often, we should wind up with dnf users testing updates before they reach other users. In case of severe regressions, dnf users should notice immediately and hopefully the package maintainer can get a corrected update out before non-dnf users even receive the bad update. I think of this as "poor man's update packs" since update batching was unfortunately removed from bodhi.

We are thinking of reworking the update cadence for Silverblue as well. I've talked to Fedora QA here in Brno and they're not opposed, but first we really have to define everything - https://teams.fedoraproject.org/project/silverblue/epic/95

This is how it works right now:

Every hour, gnome-software wakes up. It looks at the system clock and if it's past 6 am, goes and downloads new update metadata. It rate limits itself to doing it once per day to avoid excessive downloads.

Once metadata is downloaded (doesn't matter if there was any change or not), it then proceeds to download any available updates.

Once updates are downloaded, it then goes and installs any flatpaks it downloaded.

Regular rpms are immediately prepared as an offline update and made available. Once that is done, gnome-software then looks at the set of available updates; if there are any security updates, then it pops up a notification to install them. If not, then it waits until a week has passed since the last update and only then pops up a notification to install offline updates.

@kalev
Every time I login (including merely logging out and immediately logging back in), PackageKit consumes 100% CPU for a minute, laptop fans kick in, and Software uses about 1/3 of that for a slightly shorter time. If Software could check once per day, rather than once per day per login, that'd be neat.

Could the downloading of packages could be delayed by ~15 minutes; when I do testing, very often they're throw away VMs. I can't change this behavior via gsettings fast enough. And it also blocks reboot/shutdown.

The last paragraph describes downloading RPMs, and possibly waiting a week to install them. On Fedora that likely means downloading RPMs that will become stale in a week's time. I take it the RPMs themselves contain the metadata to distinguish them as security updates vs regular updates, and that this information isn't in repo metadata?

The last paragraph describes downloading RPMs, and possibly waiting a week to install them. On Fedora that likely means downloading RPMs that will become stale in a week's time. I take it the RPMs themselves contain the metadata to distinguish them as security updates vs regular updates, and that this information isn't in repo metadata?

No, that information comes from the repo metadata. gnome-software downloads them just in case so that they are ready if the user should want to install them earlier before a week has passed.

The last paragraph describes downloading RPMs, and possibly waiting a week to install them. On Fedora that likely means downloading RPMs that will become stale in a week's time. I take it the RPMs themselves contain the metadata to distinguish them as security updates vs regular updates, and that this information isn't in repo metadata?

We are talking about a released Fedora though. How many rpms are revving on a more-than-weekly basis post GA? Should not be that common, really

We are talking about a released Fedora though. How many rpms are revving on a more-than-weekly basis post GA? Should not be that common, really

Should not be that common, indeed.

Still, I think it doesn't really matter. We don't need to preemptively download updates so that the user can update quicker if she manually decides to apply updates. For most users, manual checking for updates should be quite rare, and it's OK to wait a bit for downloads when that happens. I suspect we really just want to ensure we download all updates before proposing a prepared update, and that only needs to happen weekly. Downloading the updates early annoys frequent dnf users, and the benefit of doing so is very limited, so might as well wait until we are actually going to prepare and propose an update before doing so. Fair enough?

Regular rpms are immediately prepared as an offline update and made available. Once that is done, gnome-software then looks at the set of available updates; if there are any security updates, then it pops up a notification to install them. If not, then it waits until a week has passed since the last update and only then pops up a notification to install offline updates.

Thanks for this summary.

We've previously established that we have security updates almost every day, and this is much too fast. It is extraordinarily rare for security updates to fix vulnerabilities that are being actively exploited, and such fixes should be marked urgent.

Proposal 1: Wait until a week has passed to prepare updates (including downloading updates), unless the updates are urgent priority. Do not treat security updates specially. Urgent updates should be marked urgent.

Proposal 1a): As proposal 1, except two weeks instead of one week. (I split this out separately since I expect it will be controversial, but I really do want to slow things down a bit more.)

Proposal 2: No notifications until one day after an update has been prepared. The user should have the opportunity to apply updates at power off or reboot time, when it's less inconvenient, before being pestered with notifications.

Proposal 3: Figure out a technical solution to the bug preventing the power off dialog from displaying updates reliably.

We don't need to preemptively download updates so that the user can update quicker if she manually decides to apply updates. For most users, manual checking for updates should be quite rare, and it's OK to wait a bit for downloads when that happens. I suspect we really just want to ensure we download all updates before proposing a prepared update, and that only needs to happen weekly. Downloading the updates early annoys frequent dnf users, and the benefit of doing so is very limited, so might as well wait until we are actually going to prepare and propose an update before doing so. Fair enough?

No.

How do you suggest doing that ? We propose an offline update on the logout dialog. That is not the time to go off downloading the updates. We may be offline, etc, the user may want to reboot quickly, etc etc.

Not making the user wait, ever, has been one of the core design principles behind g-s, from the very beginning. We haven't been entirely successful at that, but I don't think we should give that principle up now.

I think our current behavior is already basically following what you want to achieve - we prepare an offline update early, so users get a chance to install it at the 'less inconvenient' time every day (the poweroff dialog), and we don't pester them with notifications until a week has passed.

The one proposal that seems worth discussing is recalibrating what we consider security updates that are worth notifying about.

We are talking about a released Fedora though. How many rpms are revving on a more-than-weekly basis post GA? Should not be that common, really

If I install Fedora 31 today, reboot, go through g-i-s, immediately over 1GiB's worth of updates start downloading and I cannot stop it without a forced reboot. A normal reboot is held up with a systemd wait job on PK (downloading metadata or RPMs or both, not sure). And 4 out of 5 times I'm doing throw away installs, I don't need those updates. And also during beta, it's similar because u-t is enabled but we're also in freeze, so u-t is accumulating updates that need to be applied by default.

These are edge cases, and QA folks are used to it, but I also do throw away Windows and macOS installs and don't run into such an aggressive need to immediately download updates. I'd say UX wise, GNOME Software updates are almost as nice as macOS except for the CPU usage and inhibited reboot. It's way better than Windows updates, which I find exceptionally irritating.

Perhaps instead of a delay downloading the RPMs, if PK could self-throttle CPU and bandwidth usage for this task? Making my laptop hot on every login is just not a good UX. And if it could be interruptible so I can reboot now without having to do a force power off that'd be nice also. I don't think updates need to be available so quickly. Windows and macOS, the first update after a clean install isn't available for maybe an hour (not least of which is that it takes that long to download their incredibly massive updates.)

No.
How do you suggest doing that ? We propose an offline update on the logout dialog. That is not the time to go off downloading the updates. We may be offline, etc, the user may want to reboot quickly, etc etc.

No no, that's not what I meant. Of course I agree we should never propose an update before all packages have been downloaded.

According to Kalev's explanation, Software currently downloads updates daily even if it's not scheduled to propose an update for another week. There's not much benefit to doing that as it only saves time for the user if the user manually runs a check for updates in GNOME Software at a time when the user has not been prompted to install a prepared update. Correct? That's really just a tweak to our current behavior, not a major change and not even an essential change. The benefit would be to hopefully reduce the number of complaints we receive from 'dnf update' users. Fairly or not, it's GNOME Software that gets blamed for performing duplicate downloads and not sharing a package cache with dnf; for whatever reason, nobody seems to blame dnf for not sharing with GNOME Software....

Then maybe I misunderstood this point: "Regular rpms are immediately prepared as an offline update and made available." Does "made available" mean the update is immediately presented on the power off dialog, without first waiting for a week since the previous update? In that case, users will still wind up with daily proposed updates when powering off, just not daily notifications. My suggestion is to propose updates no more often than weekly (or biweekly). Then wait some additional time (suggestion: one day, could be even more) before nagging the user with a notification.

The benefit would be to hopefully reduce the number of complaints we receive from 'dnf update' users. Fairly or not, it's GNOME Software that gets blamed for performing duplicate downloads and not sharing a package cache with dnf; for whatever reason, nobody seems to blame dnf for not sharing with GNOME Software....

The cache is not shared because dnf doesn't have a supported api for doing so. I don't think we should accept the blame.

Does "made available" mean the update is immediately presented on the power off dialog,

That is my understanding (modulo the current gnome-shell bug). Kalev, correct me if thats wrong.

Yes, that's correct.

Metadata Update from @chrismurphy:
- Issue untagged with: meeting

a year ago

@churchyard has started: RFC: Security policy adjustments to make it easier to implement and more friendly to maintainers

While that's not directly related to this issue, if there's anything policy, infra, or RPM related that we want or need to better handle this, now might be a good time to take it into account.

The benefit would be to hopefully reduce the number of complaints we receive from 'dnf update' users. Fairly or not, it's GNOME Software that gets blamed for performing duplicate downloads and not sharing a package cache with dnf; for whatever reason, nobody seems to blame dnf for not sharing with GNOME Software....

The cache is not shared because dnf doesn't have a supported api for doing so. I don't think we should accept the blame.

Actually, you should accept the blame, as the fault mostly lies with the PackageKit developers and the DNF team not working together specifically to fix this problem. As the GNOME Software developers are also the PackageKit developers, this is partly their fault. There is also blame to be had with the DNF team, as they have not tried to rectify this either.

As for why nobody blames DNF, it's because it's not visibly DNF's fault. DNF is the package manager. Things are supposed to integrate with it, not the other way around. And all other interfaces for DNF use the shared cache in /var/cache/dnf: dnfdragora, simple-dnf, dnf-automatic, and of course dnf itself. If every frontend to libdnf actually used their own caches, then it might be a different story.

But technically the PackageKit backend could be configured to use the same cache as every other libdnf frontend. The main problem is that we don't have an API to "lock" the package manager to a single instance, as far as I know. @jmracek or @dmach might know more there.

@mclasen the DNF API for sharing the cache exists - it's the cachedir option.
PackageKit never used it. The required change needs to be made in PackageKit, libdnf or both. If you're interested in switching PackageKit to using cachedir, let us know. Please note that we'll need a commitment from your team to test PackageKit properly, debug any new issues and help us fix them in libdnf. As @ngompa suggested, it will also require proper locking and we need to make sure that running dnf clean all doesn't crash PackageKit etc.

To be honest, we are not planning any PackageKit improvements because it's a dead project for about a year.

The DNF team is planning to stop supporting the libdnf API (in upstream, support in Fedora stays for a while) used by PackageKit shortly and we'll work on a new daemon replacing PackageKit. This new daemon will share cache with DNF. I'm going to send an announcement with more details to fedora-devel in about a week.

I made a note for myself to review this issue and design an update policy for the new daemon.

Does GNOME Software have a way of acting on severity=urgent differently from any of the other severity levels? (high, medium, low)
https://github.com/fedora-infra/bodhi/blob/develop/bodhi/client/bindings.py#L262

And are package severity levels being reliably set? Are the updates tagged urgent really urgent, or are they rather high severity?

Does GNOME Software have a way of acting on severity=urgent differently from any of the other severity levels? (high, medium, low)
https://github.com/fedora-infra/bodhi/blob/develop/bodhi/client/bindings.py#L262

Yes, the data is there, but PackageKit doesn't support different security levels in its current API, so gnome-software doesn't know anything about them.

Metadata Update from @chrismurphy:
- Issue tagged with: meeting

a year ago

@mclasen the DNF API for sharing the cache exists - it's the cachedir option.
PackageKit never used it. The required change needs to be made in PackageKit, libdnf or both. If you're interested in switching PackageKit to using cachedir, let us know. Please note that we'll need a commitment from your team to test PackageKit properly, debug any new issues and help us fix them in libdnf. As @ngompa suggested, it will also require proper locking and we need to make sure that running dnf clean all doesn't crash PackageKit etc.
To be honest, we are not planning any PackageKit improvements because it's a dead project for about a year.

Yes, too late now for PackageKit. Back when PackageKit was actively developed, there was no api to share the cache, afaik.

The DNF team is planning to stop supporting the libdnf API (in upstream, support in Fedora stays for a while) used by PackageKit shortly and we'll work on a new daemon replacing PackageKit. This new daemon will share cache with DNF. I'm going to send an announcement with more details to fedora-devel in about a week.
I made a note for myself to review this issue and design an update policy for the new daemon.

It would be good to make sure that the new daemon supports all the PackageKit use cases. In particular, the offline update dance is complicated and will requires attention to avoid regressions.

General agreement to reduce the frequency of non-urgent updates to not more than once per week (TBD); and there needs to be a reliable mechanism to indicate truly "urgent" severity updates (possibly entailing automation such that Bodhi requires a bugzilla with CVE reference, to consider an update urgent, otherwise it's demoted to "medium" severity).

ack/nack/patch?

@mattdm is on vaca this week, so tentatively push this issue back to 03 March to give him some time to dig out upon return.

Metadata Update from @chrismurphy:
- Issue untagged with: meeting

a year ago

My vote: all non-urgent updates get batched every two weeks. (Weekly is still a bit much!) Start with client-level batching in gnome-software, because that's what we can do today. Ideally in a better future, bodhi would learn to batch updates itself once again, so we can have lightly-tested "update packs" that get sanity-checked by OpenQA.

The definition of what makes a security update urgent is a bit hazy. In general, I'd say only critical-severity CVEs are urgent, or important CVEs actively exploited in the wild (very rare), or CVEs that are receiving special media attention (such that the CVE is an urgent PR issue). I'd also say the update is not urgent if mitigated by a sandbox (so e.g. critical CVEs in Firefox are not urgent, unless the CVE is a sandbox escape). I suggest we trust maintainers to set the priority level of their updates appropriately, using their best judgment, and in accordance with considerations that we document in the Fedora updates policy (which might look like what I just wrote). Abuse can be reported to FESCo to be handled on a case-by-case basis.

None of the above applies to flatpaks. Flatpaks can be updated automatically at any time. In the future, we might want to selectively begin shipping some default apps as flatpaks, e.g. Firefox. (But probably not before we have debuginfo for Fedora flatpaks, and ABRT integration.)

Is there a useful way to informally parse repo metadata over the next 3-7 days, for "urgent" severity updates? Would this help estimate whether this designation might be useful or problematic?

None of the above applies to flatpaks. Flatpaks can be updated automatically at any time. In the future, we might want to selectively begin shipping some default apps as flatpaks, e.g. Firefox. (But probably not before we have debuginfo for Fedora flatpaks, and ABRT integration.)

That's probably not smart to make that assumption. Flatpaks are just as dangerous given that they can easily destroy user data with the sandbox. That's what people care about, and you're suggesting that doesn't matter, when it probably matters more to people.

General agreement to reduce the frequency of non-urgent updates to not more than once per week (TBD); and there needs to be a reliable mechanism to indicate truly "urgent" severity updates (possibly entailing automation such that Bodhi requires a bugzilla with CVE reference, to consider an update urgent, otherwise it's demoted to "medium" severity).
ack/nack/patch?

One point that was raised yesterday: urgent doesn't necessarily mean "security issue of a certain severity". That could potentially invalidate the "requires a bugzilla with a CVE ref" approach.

The main difficulty in all this is the word "reliable". We need to be realistic in our expectations for what can be achieved while individual maintainers are in control of what gets updated when.

If updates that genuinely need to be pushed out urgently are rare, wouldn't it be possible to have some kind of centralised process for that? If the update needs to go out urgently, the maintainer has to ask person foo and they push a special button.

There is a proposal for updates policy on Fedora Silverblue, most of it can be adapted even for "vanilla" Workstation.

https://docs.google.com/document/d/1gz1inA8e_LQP-dO751bkpS_ZVVLFAqYwFiRlqKJ3G9g/edit?usp=sharing

Comments welcome :)

Very rough draft outline of steps for implementing this. Feel free to reorder, restate, or do a rewrite, fill in details - I'm just trying to get this started so we're prepared for what we know and don't know, what we need but don't yet have, gotchas, etc.

https://etherpad.gnome.org/p/ReconsiderUpdatesPolicy

Yes, the data is there, but PackageKit doesn't support different security levels in its current API, so gnome-software doesn't know anything about them.

I'm confused. If gnome-software doesn't know about severity levels, why are update notifications happening so often? In particular, this diagram's "Are they critical?"

What is asking and answering that question?

Metadata Update from @chrismurphy:
- Issue tagged with: meeting-request

a year ago

@mattdm is scheduled to join us for the 17 Mar meeting.

Yes, the data is there, but PackageKit doesn't support different security levels in its current API, so gnome-software doesn't know anything about them.

This was just a typo. Kalev meant to write that PackageKit doesn't currently support different severity levels.

It does distinguish between security and non-security updates.

Yes, the data is there, but PackageKit doesn't support different security levels in its current API, so gnome-software doesn't know anything about them.

This was just a typo. Kalev meant to write that PackageKit doesn't currently support different severity levels.
It does distinguish between security and non-security updates.

Yes and no: packagekit has different severity levels, and one of them is a "security" severity level. So it does support distinguishing between security and non-security updates, but doesn't distinguish between different security update severity levels.

I see in Bodhi (both web and CLI views) these two fields

  • type [newpackage, security, bugfix, enhancement]
  • severity [unspecified, urgent, high, medium, low]

But they are separate fields. Near as I can tell from the interface, they relate only by convention or implication. I think severity describes the update, not the type field value. But...I don't know.

Right. But in PackageKit it's all mangled up, so the update type/severity goes like [ unknown, low, normal, important, security ] (or something along those lines, I'm writing from memory).

This is all of course just implementation details and should be easily fixable if we manage to convince hughsie to include new API in PackageKit (it's in deep maintenance mode right now).

I'm pretty sure PK does support the various update states; it's in the API: https://github.com/hughsie/PackageKit/blob/master/lib/packagekit-glib2/pk-enum.h#L622 -- although I don't believe the DNF backend actually sets it. From memory PK uses the same states that were defined by yum all those years ago.

But it seems there are too many security updates

I don't think you can ask people filing bugs to not mark them as security, nor do I think you can ask the user to specify a CVSS score they consider "important enough".

I don't think you can ask people filing bugs to not mark them as security, nor do I think you can ask the user to specify a CVSS score they consider "important enough".

None of this is a problem. We don't want to change how packagers prepare updates, only how GNOME Software prioritizes them. My proposed new desired behavior is:

  • Check for updates daily
  • Notify user that updates are available if (a) two weeks have passed since the last update, or (b) if an update is marked urgent
  • (Of course, manually checking for updates should always display all available updates)
  • Do not treat security updates specially. If a security update is urgent, it should be marked urgent; otherwise, it can wait two weeks.

I like that plan, especially given it's easily implementable without needing PackageKit API changes. +1 from me.

I do think we need some updated notifications though so that people wouldn't be wondering why they are getting update notifications before 2 weeks have passed.

Currently the update notification reads:
Software Updates Available
Important OS and application updates are ready to be installed
[Not Now] [View]

Can we somehow change the notification so that it says when there's an urgent update? And maybe remove "important" from the regular notification when no urgent updates are included?

Some ideas,
Urgent Software Updates Available
Urgent Firefox, KDE filesystem, and 5 more updates are available
[Not Now] [View]

So basically just adding "urgent" for urgent update notifications and spelling out the names of the urgent updates, maybe? Or should we handwave "KDE filesystem" in some way to avoid spelling out system components?

I'll note that when urgent updates are available, we should be always applying all updates, not just cherry picking the urgent ones (this can easily lead to broken systems as we don't QA cherry-picked combinations).

I do think we need some updated notifications though

I'd like to do a review of all the updates notifications - upstream issue for this.

One question about the proposal: what about if we have updates we want to push out immediately after a release?

One question about the proposal: what about if we have updates we want to push out immediately after a release?

If you're upgrading from a previous release, you get the updates as part of the distro upgrade.

If you've just installed fresh, you should be notified about updates immediately because there has not been a successful system update during the past two weeks (or ever).

I like the proposal so far. A possible glitch I can't fully estimate:

$ bodhi updates query --severity=urgent --rows 100

Firefox is often urgent. Sometimes the kernel is. I figure a default installation might get an urgent update once every two weeks, variably. That's better than now. But a more "aged" system may see urgent update notifications more than once per week, possibly back to back days.

Metadata Update from @chrismurphy:
- Issue untagged with: meeting-request
- Issue tagged with: meeting

a year ago

Agreed: the WG likes the GNOME Software proposal.

We'll continue discussing with Matthew Miller next week.

Clarification requested. Bodhi provides type distinct from severity. Is the idea that the user is notified of severity=urgent updates, regardless of type=security,bugfix,enhancement,newpackage? Or only when type=security and severity=urgent?

A question and a comment...

Do we have data on how often updates are tagged with "urgent"?

And the comment: urgent bugfixes should probably also be considered as exceptions, because they may be needed to prevent data loss. But we should also discourage packagers from tagging things as urgent in lesser cases. If it turns out that that's a problem. I really have no idea right now.

Clarification requested. Bodhi provides type distinct from severity. Is the idea that the user is notified of severity=urgent updates, regardless of type=security,bugfix,enhancement,newpackage? Or only when type=security and severity=urgent?

Whenever severity=urgent, because an urgent update is urgent and delaying urgent updates doesn't make sense.

We won't look at type=security at all.

Do we have data on how often updates are tagged with "urgent"?

$ bodhi updates query --severity=urgent --rows 100

So that's 100 updates over ... 243 days. Not so great for reducing notifications. I guess that should be filtered out by "packages on the workstation default install set". Some of them seem like they're pretty obscure in practice. Too bad we don't have popcon.

We'll certainly need to ask maintainers to use it more sparingly. E.g. a Firefox update is not urgent unless it fixes a Linux sandbox escape, or a truly critical non-security bug like the recent spurious certificate verification failures. There will never be any shortage of vulnerabilities, but having a sandbox allows us the freedom to wait two weeks to update.

We discussed this today with mattdm and everyone seems to still be on board.

The remaining question that we didn't resolve during the meeting is whether we do updates every two weeks (my proposal), or weekly (as we do now). I suggest we go with two weeks unless somebody wants to advocate for the weekly option.

Metadata Update from @catanzaro:
- Issue untagged with: meeting

a year ago

General consensus to proceed with this change to GNOME Software behavior:

  • regular update notifications will happen not more than once per week, ideally once every two weeks
  • availability of "urgent" severity updates, of any type, will cause a notification to appear to inform and encourage the user to apply updates
  • when there are urgent updates to apply, all available updates (any type and severity) will also be applied at the same time

Additionally:

  • ask FESCo to decide on a policy to define "urgent" severity; taking into account that severity applies to all types of updates: security,bugfix,enhancement,newpackage; and that "urgent" means the user will be a) notified of such updates very soon and b) asked to reboot to apply updates. (implies a FESCo ticket)
  • inform packagers of the policy (implies devel@ email following FESCo ticket resolution)

@aday, regarding your gnome-software design changes, could we change the end session dialog to prompt to install updates by default?

Sure, makes sense

We agreed non-urgent updates will occur every two weeks.

We agreed non-urgent updates will occur every two weeks.

Kalev, were you going to implement this in gnome-software?

We agreed non-urgent updates will occur every two weeks.

Kalev, were you going to implement this in gnome-software?

Yes.

We're approaching the end of the current release cycle. Are you still targeting 3.38 for this?

My plan was to spend some time next week looking at this. Let's see how far we get with this then.

I guess this will slip to next cycle?

Yes, I think so at this point.

Metadata Update from @aday:
- Issue set to the milestone: Fedora 34

8 months ago

Looks like this is still stalled.

@mcrha, is this something you could help with? The desired policy is:

  • regular update notifications will happen not more than once per week, ideally once every two weeks
  • availability of "urgent" severity updates, of any type, will cause a notification to appear to inform and encourage the user to apply updates
  • when there are urgent updates to apply, all available updates (any type and severity) will also be applied at the same time

Let's start with updates once per week for now. We could always switch to two weeks in the future, but I'm worried that delaying Firefox updates that long might result in unhappy users.

And to clarify the second point: GNOME Software should no longer prioritize security updates for immediate notification. It should only prioritize Urgent updates, regardless of whether it is a security update or not.

We have an ongoing discussion about this with @aday at the moment.

Hi Milan, any updates here?

Yeah, I plan to cover this within https://gitlab.gnome.org/GNOME/gnome-software/-/issues/182 , and I have it in my short term To Do, in fact I wanted to make a proposal the last week, but I've been distracted with other work, thus it has got postponed. I'm about to review a large change upstream and then I plan to look on this.

I guess this got fixed? @mcrha do you have any advice around testing these changes?

Yes, this is now fixed, in theory. Thanks so much Milan!

Testing updates is a little tricky. I think the best approach is going to be to keep a record of how often we are prompted to update in Fedora 34. If it's more than every two weeks, then that should be clearly attributable to a particular update that was marked as Urgent. If not, we have a problem.

I'm going to close this for now. If we think it's not working properly, then we can revisit, of course.

Metadata Update from @catanzaro:
- Issue close_status updated to: Fixed
- Issue status updated to: Closed (was: Open)

4 months ago

I would personally like to have some kind of verification that the changes are working as expected. It could be as simple as documenting the intended behaviour and have a few people look out for updates notifications to see if they are behaving as expected.

Verification sounds good.

You can also count on me to take yell and start taking notes on my proposed updates if I suspect it's not working as intended. ;)

do you have any advice around testing these changes?

The only thing I can think of, apart of playing with the code, is to check the:

   $ gsettings get org.gnome.software update-notification-timestamp

The other option is to run gnome-software with --verbose, which will print why it claimed, or why not, the update notification. Grep the output for should_notify_about_pending_updates.

One more thing, you can modify the GSettings key to simulate the day moves.

@mrcha thanks, that's useful! Could you give us a summary of the behaviour as implemented? That would help with testing.

Reopening since Milan says this was not fully implemented, see https://bugzilla.redhat.com/show_bug.cgi?id=1930401#c22.

Metadata Update from @catanzaro:
- Issue status updated to: Open (was: Closed)

3 months ago

To be precise, the upstream change does not change the classification of the updates, thus any security update is considered as a "critical urgency" and any "important" update is considered as a "high urgency". The code considers important both high & important updates.

This needs to be filled upstream [1] and discussed there first.

[1] https://gitlab.gnome.org/GNOME/gnome-software/-/issues

OK, but keep in mind Workstation WG only sets policy for Fedora. That is, even if upstream rejects the change, it still needs to be implemented in Fedora.

Thanks, I proposed a change there.

Thanks, I proposed a change there.

Thanks for looking into it, Milan. It seems your GNOME Software change is stalled pending PackageKit API changes, which nobody is assigned to implement. So this falls back to the Working Group....

Metadata Update from @catanzaro:
- Issue tagged with: meeting

3 months ago

It seems your GNOME Software change is stalled pending PackageKit API changes, which nobody is assigned to implement. So this falls back to the Working Group....

Do we have an issue or PR for those changes? I don't see one.

Right, I kind of forgot to update this ticket with the findings from https://gitlab.gnome.org/GNOME/gnome-software/-/merge_requests/648#note_1055290 and above that comment. Long story short: libdnf mimics bodhi (or vice versa), there's an update severity and an update kind. The problem is that the PackageKit doesn't expose (neither uses) the severity, it only exposes the kind.

Your request here is to recognize update notification importance solely on the severity.

The issue is interconnected, the libappstream doesn't have any such thing like severity, it also has only the kind. That's important, because gnome-software uses enums from the libappstream.

What to do depends how great (and clean) the change should be. I can foresee two options: either add the severity everywhere and use it instead of the kind for the notifications, or extend the kind with "urgent" and check only for the urgent severity in the PackageKit. The later has its limitations, as you can see. There can be other possibilities too, these are just two I can think of right now.

ACTION: Neal to discuss with Milan and determine whether PackageKit changes are really needed here

Metadata Update from @catanzaro:
- Issue untagged with: meeting
- Issue tagged with: pending-action

3 months ago

Right, I kind of forgot to update this ticket with the findings from https://gitlab.gnome.org/GNOME/gnome-software/-/merge_requests/648#note_1055290 and above that comment. Long story short: libdnf mimics bodhi (or vice versa), there's an update severity and an update kind. The problem is that the PackageKit doesn't expose (neither uses) the severity, it only exposes the kind.

This is curious, because Cockpit exposes the severity and it also uses PackageKit, so I wonder how it's doing it if the PackageKit API isn't normally offering this.

Okay, so Cockpit just confuses severity with type. We may need an API extension in PackageKit, which should hopefully not be too bad to do...

As I said in today's meeting, one thing that we're obviously missing is a way to programatically test changes like this. Without that, it is impossible to a) know what users are going to get in terms of experience or b) iteratively improve the design.

That said, I do wonder whether having so much logic in the client is one of the reasons for these testing woes. If we do conclude that the current design approach is impossible to test that might be a reason to look at this whole subject afresh.

Metadata Update from @aday:
- Issue untagged with: pending-action

3 months ago

Cockpit's 'severity' looks like it's bodhi's 'type' which is either newpackage, security, bugfix, enhancement. The number after the bugfix or security icon appears to be a reference to a rhbz associated with a particular updateid. I'm not sure how that is exposed via packagekit to cockpit, but it does not correlate with bodhi's 'severity' which is either unspecified, urgent, high, medium, low.

That said, I do wonder whether having so much logic in the client is one of the reasons for these testing woes. If we do conclude that the current design approach is impossible to test that might be a reason to look at this whole subject afresh.

The gnome-software has some internal tests, but I do not see any similar for the PackageKit. The reason might be that providing updates for the PackageKit is not that simple as with the Flatpak plugin (the Flatpak plugin does quite a lot of things, including updates).

I do not know whether I understood your question correctly though.

In any case, libdnf returns only strings. PackageKit transforms the update type into an enum and it doesn't have anything like that for the severity (because PackageKit doesn't use severity at all, I suppose). If there can be assured the severity string will be one of the predefined values, then it'll make things much simpler. I'd not define the enum on the PackageKit side, it can be done on the gnome-software side instead. I do not know how to get the values libdnf can return, is that anyhow dictated by the bodhi itself? I checked the PackageKit code briefly and exposing the severity might not be a toy, depending how hackish the change would be (the change either requires to add a new parameter to pk_backend_job_package (it's used a lot and it's a semi-public API function) or add a new variant of it, with added severity argument).

That said, I do wonder whether having so much logic in the client is one of the reasons for these testing woes. If we do conclude that the current design approach is impossible to test that might be a reason to look at this whole subject afresh.

The gnome-software has some internal tests, but I do not see any similar for the PackageKit. The reason might be that providing updates for the PackageKit is not that simple as with the Flatpak plugin (the Flatpak plugin does quite a lot of things, including updates).

I do not know whether I understood your question correctly though.

One issue is that, since we don't batch updates on the server side, we implement the batching logic on the client side (say by waiting 2 weeks before notifying the user about updates). Practically speaking, that's a difficult thing to test.

I've filed a ticket with the DNF team for an API for severity: https://bugzilla.redhat.com/show_bug.cgi?id=1959066

I've filed a ticket with the DNF team for an API for severity: https://bugzilla.redhat.com/show_bug.cgi?id=1959066

The libdnf provides the severity, it's the PackageKit not passing it forward.

Just a note, I'm (slowly) working on the PackageKit side of this, adding the required API. Once done, it can be used on the gnome-software side. I'll update the above bug accordingly.

A little status update:
* the PackageKit upstream accepted the change, it'll be part of the 1.2.4 release, if I'm not mistaken. What date it's planed for I do not know.
* the gnome-software upstream accepted the change, which will be part of the 40.2 release, which will happen this Friday.

That means, once the PackageKit is built with the patch (either by adding it as a custom change to the 1.2.3 package or when the 1.2.4 is released) and gnome-software is rebuilt against it, the things will start working as is requested here. I do not have commit rights for the PackageKit package, but I'd not add the patch there myself anyway, because I do not maintain the package. Such things should be done by the maintainer.

Thanks Milan! I think it's sufficient for this change to land in rawhide after the next PackageKit release.

For Fedora 34, the priority is to fix the two major regressions (a) system updates no longer prepared automatically, (b) flatpak apps no longer updated daily. I see both are already fixed in gnome-software 40.2, which is good.

Login to comment on this ticket.

Metadata