Add new 'update-kind' / 'update-type' property for PkPackage

[sidt4]

From: #729

As discussed in #729 (comment) and #729 (comment), I think we should introduce a new update-kind / update-type property, and use it for setting the following update types:

• PK_INFO_ENUM_ENHANCEMENT
• PK_INFO_ENUM_BUGFIX
• PK_INFO_ENUM_SECURITY

I'll submit a PR if we're ok with the premise of this issue.

[ximion]

That would be a breaking change though, or would duplicate the existing method of conveying that information. Do you really think that's worth it?

[sidt4]

That would be a breaking change though

Did you mean from an API perspective ?

Do you really think that's worth it?

We're trying to multiplex 2 different types of information in a single property update-severity.

Few observations:

1. PK_INFO_ENUM_ENHANCEMENT is not a severity level. The sooner we fix this, the lesser PK clients would write bad code, and would have to change later.
2. If a PK client decides to highlight all critical updates ( as currently done in GS below ) and bug fixes / enhancements separately in the UI, there would be no way to do this currently.
   
3. As shown in PkPackage: Handle all cases for 'update-severity' property #729 (comment), apt backend does heuristic stuff. I was trying to display security updates as Critical in Debian 12 for firefox-esr, which works correctly in Fedora, but not in Debian as we don't set a severity level in apt backend. What is the recommend way to achieve this in PK apt backend ?

[sidt4]

If it's a lot of work, we can address [3] for now as only apt and dnf use pk_package_set_update_severity () currently.

Also, I think we should create a Packagekit-2.0 git label, label this issue and make the proper fix later.

[sidt4]

FWIW, GS does extra stuff if the update is >= AS_URGENCY_KIND_CRITICAL. ( Refer https://gitlab.gnome.org/GNOME/gnome-software/-/blob/main/plugins/packagekit/gs-plugin-packagekit.c#L2804-L2820 )

./src/gs-update-monitor.c:132:		is_important = gs_app_get_update_urgency (app) >= AS_URGENCY_KIND_CRITICAL;
./src/gs-update-monitor.c:573:		if (gs_app_get_update_urgency (app) >= AS_URGENCY_KIND_CRITICAL &&
./src/gs-app-row.c:510:	gtk_widget_set_visible (priv->update_critical_image, priv->show_update && gs_app_get_update_urgency (priv->app) >= AS_URGENCY_KIND_CRITICAL);
./src/gs-os-update-page.c:147:	if (gs_app_get_update_urgency (app) >= AS_URGENCY_KIND_CRITICAL) {
./src/gs-os-update-page.c:183:	critical_update_message = (gs_app_get_update_urgency (app) >= AS_URGENCY_KIND_CRITICAL) ? _("Critical update") : "";

• One is the exclamation (emblem-important-symbolic icon) next to the app ( as shown in above comment )
• Another is to send a notification with a special message to update asap.

Neither of which currently works in current Debian stable when there are security updates.

[ximion]

1. PK_INFO_ENUM_ENHANCEMENT is not a severity level.

It is though. It's the lowest priority level for an update. Granted, the whole high/low enhancement/bugfix tagging is an absolute mess and beyond confusing. But when trying to fix it without breaking backwards compatibility, I fear we will just create even more confusion and an even bigger mess.

3. apt backend does heuristic stuff. I was trying to display security updates as Critical in Debian 12 for firefox-esr, which works correctly in Fedora, but not in Debian as we don't set a severity level in apt backend. What is the recommend way to achieve this in PK apt backend ?

Package updates do have a severity on their own. The overall repo defines the package's fix category (that's what the heuristics is for), and the serveity could be read from the package's changelog. The problem is, pulling the changelog is a separate and potentially slow HTTPS request, and we also have to parse the changelog, making this fairly annoying.

Neither of which currently works in current Debian stable when there are security updates.

Debian distinguishes between high-priority security updates (install ASAP) and critical updates (drop everything you're doing, install immediately!). To distinguish them, we would need changelog parsing in the backend at an earlier stage (currently its only done when details are requested, as it's not very fast)...

[sidt4]

It is though. It's the lowest priority level for an update. Granted, the whole high/low enhancement/bugfix tagging is an absolute mess and beyond confusing. But when trying to fix it without breaking backwards compatibility, I fear we will just create even more confusion and an even bigger mess.

Okay.

Package updates do have a severity on their own. The overall repo defines the package's fix category (that's what the heuristics is for), and the serveity could be read from the package's changelog. The problem is, pulling the changelog is a separate and potentially slow HTTPS request, and we also have to parse the changelog, making this fairly annoying.

Yes. GS made the change a couple of release ago, where previously we downloaded full changelogs during update check (https://gitlab.gnome.org/GNOME/gnome-software/-/issues/2230). It was later changed to be loaded on demand and update loading is much faster now.

The main issue here is to highlight security issues as critical in Debian stable ( as in fedora ) for a start.

I see 2 solutions:

1. Make the change in PK apt backend ( set severity to critical than security if from debian security repo )
2. Make the change in GS ( set update as critical if severity is critical or security )