Bug 1950041 - PackageKit metadata refresh fail: .repo file metadata_expire changes
Summary: PackageKit metadata refresh fail: .repo file metadata_expire changes
Keywords:
Status: CLOSED EOL
Alias: None
Product: Fedora
Classification: Fedora
Component: PackageKit
Version: 34
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Richard Hughes
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: 1903294
TreeView+ depends on / blocked
 
Reported: 2021-04-15 15:52 UTC by Rex Dieter
Modified: 2022-12-01 21:43 UTC (History)
9 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2022-06-08 00:45:16 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Rex Dieter 2021-04-15 15:52:10 UTC
Could be a feature not a bug, but thought I'd mention in case it's possible to address.

While testing PK metadata cache issues, I found a case where dnf and PK metadata cache's were out of sync (not uncommon).  dnf reported a pkg foo from repo bar had an update available, but PK didn't refresh yet.  The Packagekit metadata was somewhere between 12-24hrs old, at least by eyeballing timestamps of stuff under /var/cache/PackageKit/

As a test, I went to the bar.repo file and added
metadata_expire=1h

and ran:
pkcon refresh

I was expecting PackageKit to refresh the repo bar metadata and report and update available, except it didn't. :(

Comment 1 Neal Gompa 2021-04-15 16:18:50 UTC
The only change I've seen here on this is: https://github.com/hughsie/PackageKit/commit/54a616b8edb8391f90ae183989bd98aa87e26b14

Prior to that was my change to read all repo and var directories: https://github.com/hughsie/PackageKit/commit/ed73aa6317595d2c2f1bda7990cbd64efb133f84

Neither of which should have had an impact on this...

Comment 2 Neal Gompa 2021-09-30 10:55:16 UTC
As this has now come up with GNOME Software, I should actually write my findings here...

During F34 development, I discovered that PackageKit defaults cache-age to UINT_MAX, which effectively means calling refresh (without force) will do nothing, since it won't ever expire anything. PackageKit also doesn't seem to respect DNF's repo expiration settings, which isn't helping...

I'm not sure what we should do here, actually. Should we fix PackageKit to expire repos based on the backend's report of the repo cache age? Or should we change the default value to something smaller globally (that is, for all backends)?

Comment 3 Milan Crha 2021-09-30 11:39:15 UTC
Does to that count also when one uses `pk_client_refresh_cache` with preceded call to `pk_client_set_cache_age`? [1] I'd expect this is used instead of the UINT_MAX.

[1] https://gitlab.gnome.org/GNOME/gnome-software/-/blob/gnome-40/plugins/packagekit/gs-plugin-packagekit-refresh.c#L183

Comment 4 Rex Dieter 2021-09-30 11:50:52 UTC
For comment #2 , my opinion is both: Implement both a better/sane default value *and* respect the backend's cache age setting if present (the latter being the primary reason this bug was opened in the first place).

Comment 5 Ben Cotton 2022-05-12 16:27:56 UTC
This message is a reminder that Fedora Linux 34 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora Linux 34 on 2022-06-07.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
'version' of '34'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, change the 'version' 
to a later Fedora Linux version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora Linux 34 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora Linux, you are encouraged to change the 'version' to a later version
prior to this bug being closed.

Comment 6 Ben Cotton 2022-06-08 00:45:16 UTC
Fedora Linux 34 entered end-of-life (EOL) status on 2022-06-07.

Fedora Linux 34 is no longer maintained, which means that it
will not receive any further security or bug fix updates. As a result we
are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release.

Thank you for reporting this bug and we are sorry it could not be fixed.

Comment 7 Christian Tosta 2022-11-30 18:30:37 UTC
Still fails on Fedora 37. See the PackageKit issue #588 and KDE #461962:

https://github.com/PackageKit/PackageKit/issues/588
https://bugs.kde.org/show_bug.cgi?id=461962

Comment 8 Alessandro Astone 2022-12-01 21:43:06 UTC
(In reply to Christian Tosta from comment #7)
> Still fails on Fedora 37. See the PackageKit issue #588 and KDE #461962:
> 
> https://github.com/PackageKit/PackageKit/issues/588
> https://bugs.kde.org/show_bug.cgi?id=461962

Fedora applies a patch to discover that forces packagekit to rebuild the cache when checking for updates: https://src.fedoraproject.org/rpms/plasma-discover/blob/f37/f/discover-5.21.4-pk_refresh_force.patch
It seems to do its job on my system. Are you perhaps building discover yourself without the patch?


Note You need to log in before you can comment on or make changes to this bug.