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.
(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.
(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).
And this one isn't fixed ? Apper and kde updates are running well now .
Apper now sets an explicit cache-age hint, but pkcon does not yet, afaik
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.
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.