Bug 1201938 - pkcon refresh uses infinite cache age by default, making it a noop
Summary: pkcon refresh uses infinite cache age by default, making it a noop
Keywords:
Status: CLOSED EOL
Alias: None
Product: Fedora
Classification: Fedora
Component: PackageKit
Version: 21
Hardware: Unspecified
OS: Linux
unspecified
medium
Target Milestone: ---
Assignee: Richard Hughes
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-03-13 21:39 UTC by Tomáš Trnka
Modified: 2021-12-10 14:28 UTC (History)
9 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-12-02 10:03:54 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 1188207 0 unspecified CLOSED Apper won't check for updates even when user asks it to, and misses updates 2021-02-22 00:41:40 UTC
Red Hat Bugzilla 1189602 0 unspecified CLOSED PackagetKit reports no updates are available 2021-02-22 00:41:40 UTC
Red Hat Bugzilla 1206760 0 unspecified CLOSED Plasma live session notifies for available updates 2021-02-22 00:41:40 UTC

Internal Links: 1188207 1189602 1206760

Description Tomáš Trnka 2015-03-13 21:39:54 UTC
Description of problem:
Running "pkcon refresh" does not actually refresh the cache by default, as the transaction is created with cache_age set to infinity and thus the hif backend function hif_source_check() skips checking the age of cached metadata and always indicates it is fresh.

One has to explicitly set a permissible cache age using e.g. "pkcon -c 86400 refresh" to get something useful.

This is essentially the same problem as bug 1188207, though that one deals with Apper and this one with pkcon.

Version-Release number of selected component (if applicable):
PackageKit-1.0.4-1.fc21.x86_64
libhif-0.1.8-4.fc21.x86_64

How reproducible:
Any time

Steps to Reproduce:
1. Use GDB to watch the calls to hif_source_check() by packagekitd 
2. Run "pkcon refresh"
3. Notice that all calls have the permissible_cache_age argument set to G_MAXUINT and the return value is always 1

Actual results:
"pkcon refresh" doesn't do anything useful.

Expected results:
The "refresh" operation should by default force some finite cache age, in order to do what the user reasonably expects.

Additional info:
It would probably be best to make libhif honor the metadata_expire setting for Yum repos, instead of relying on the caller to provide a reasonable cache age. The optimal cache age may dramatically differ between repos.

Comment 1 Richard Hughes 2015-04-27 11:18:28 UTC
(In reply to Tomáš Trnka from comment #0)
> The "refresh" operation should by default force some finite cache age, in
> order to do what the user reasonably expects.

That's the problem. We have to guess what the user is trying to do; "1 minute" is suitable for the person who's just pushed a new tree, but "24h" is probably what some other people want. Some would argue for 1h, some would argue for 4h.

> It would probably be best to make libhif honor the metadata_expire setting
> for Yum repos, instead of relying on the caller to provide a reasonable
> cache age. The optimal cache age may dramatically differ between repos.

We're deliberately not using that by default, as metadata_expire doesn't take into account the user timeouts, for instance if the user has set to check for updates once per day at 5pm, a metadata_expire of 24 hours might not match the "start time" and thus the metadata wouldn't be <= 24h old but up to 48h old.

Comment 2 Tomáš Trnka 2015-04-27 11:58:18 UTC
(In reply to Richard Hughes from comment #1)
> (In reply to Tomáš Trnka from comment #0)
> > The "refresh" operation should by default force some finite cache age, in
> > order to do what the user reasonably expects.
> 
> That's the problem. We have to guess what the user is trying to do; "1
> minute" is suitable for the person who's just pushed a new tree, but "24h"
> is probably what some other people want. Some would argue for 1h, some would
> argue for 4h.

I completely agree with you that this is a correct approach for the backend. However, pkcon is a frontend that should IMHO be at least a little user friendly. The fact that plain "pkcon refresh" does nothing by definition is certainly not apparent to users. (Even the console output seems to indicate that it is in fact refreshing the repos.) I'd wager that any non-infinite default value would be more sensible than the current (infinite) default.

However, if you really don't want to set a different default cache age, what about at least throwing a clear warning/error when someone runs "pkcon refresh" without setting the age? It would be miles more user friendly than the current state, where one has to go digging through the source code just to figure out why it's not refreshing.

> > It would probably be best to make libhif honor the metadata_expire setting
> > for Yum repos, instead of relying on the caller to provide a reasonable
> > cache age. The optimal cache age may dramatically differ between repos.
> 
> We're deliberately not using that by default, as metadata_expire doesn't
> take into account the user timeouts, for instance if the user has set to
> check for updates once per day at 5pm, a metadata_expire of 24 hours might
> not match the "start time" and thus the metadata wouldn't be <= 24h old but
> up to 48h old.

Sure, it would be a little bit tricky to get right, though I still think the repo administrator has a much better idea of how often the repo gets updated than any ordinary user (who can just guess whether refreshing every two hours or three days is more sensible).

Comment 3 Sergio Basto 2015-05-13 18:39:37 UTC
And this one isn't fixed ?   Apper and kde updates are running well now .

Comment 4 Rex Dieter 2015-05-13 19:44:59 UTC
Apper now sets an explicit cache-age hint, but pkcon does not yet, afaik

Comment 5 Fedora End Of Life 2015-11-04 11:59:29 UTC
This message is a reminder that Fedora 21 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 21. 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 Fedora  'version'
of '21'.

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

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 21 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, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Comment 6 Fedora End Of Life 2015-12-02 10:03:58 UTC
Fedora 21 changed to end-of-life (EOL) status on 2015-12-01. Fedora 21 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. If you experience problems, please add a comment to this
bug.

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


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