Bug 740331 - Maximum metadata age should be check interval minus 30 minutes
Summary: Maximum metadata age should be check interval minus 30 minutes
Keywords:
Status: CLOSED NEXTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: PackageKit
Version: 15
Hardware: All
OS: Linux
unspecified
unspecified
Target Milestone: ---
Assignee: Richard Hughes
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-09-21 16:46 UTC by Kevin Kofler
Modified: 2011-09-22 10:20 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-09-22 10:20:21 UTC


Attachments (Terms of Use)

Description Kevin Kofler 2011-09-21 16:46:18 UTC
(not just the check interval)

As per bug #740305:
> Plus, the max cache age probably needs to be the GUI update frequency minus
> something, or you'll end up with:
> * update check set to once per 3 days
> * GUI starts checking for updates on Monday at 12:00
> * update check completes on Monday at 12:01
> * GUI starts checking for updates on Thursday at 12:00 (exactly 3 days later)
> * cache is 2 days 23 hours 59 minutes old
> * zif sees it's not 3 days old, does nothing
> * EPIC FAIL ;-)
[…]
> Let's make it half an hour. KPK's minimum check time is hourly, and 1 hour
> minus 1 hour = 0, oops…

Comment 1 Kevin Kofler 2011-09-21 22:40:45 UTC
The question is: Where in the food chain do we want to subtract those 30 minutes? In the PackageKit core, between the value set by the frontend and the value passed to the backend, would probably be the best place to avoid code duplication, but then the "cache-age" name for the property might be misleading…

Comment 2 Richard Hughes 2011-09-22 10:12:05 UTC
(In reply to comment #1)
> The question is: Where in the food chain do we want to subtract those 30
> minutes? In the PackageKit core, between the value set by the frontend and the
> value passed to the backend, would probably be the best place to avoid code
> duplication, but then the "cache-age" name for the property might be
> misleading…

I think the only place it makes sense to subtract is in the PK _backend_, so that the user sends "24 hours" and this gets transformed by pk-backend-%foo.c into a cache_age of "23 hours, 30 minutes"

The backends themselves only care about cache ages, and the frontends don't want to get into the complexity (and are already doing one thing) so I think doing this in the backend makes perfect sense.

I'll work on fixing this now.

Richard.

Comment 3 Richard Hughes 2011-09-22 10:20:21 UTC
commit 6ab9b742bc230bd3ac8a6479ea737e9557ee1843
Author: Richard Hughes <richard@hughsie.com>
Date:   Thu Sep 22 11:19:35 2011 +0100

    Offset the cache age by 30 minutes
    
    We have to offset the cache age by 30 minutes if possible to account
    for the possible delay in running the transaction, for example:
    
    * Update check set to once per 3 days
    * GUI starts checking for updates on Monday at 12:00
    * Update check completes on Monday at 12:01
    * GUI starts checking for updates on Thursday at 12:00 (exactly 3 days later)
    * Cache is 2 days 23 hours 59 minutes old
    * Backend sees it's not 3 days old, does nothing
    
    Many thanks to Kevin Kofler for finding the problem.


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