Bug 740305 - Zif default metadata expiry time is too long
Summary: Zif default metadata expiry time is too long
Keywords:
Status: CLOSED NEXTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: zif
Version: 15
Hardware: x86_64
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: 2011-09-21 15:17 UTC by Cody
Modified: 2011-09-21 22:28 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-09-21 16:33:37 UTC


Attachments (Terms of Use)
Output of zif -v update (561.41 KB, application/octet-stream)
2011-09-21 15:17 UTC, Cody
no flags Details

Description Cody 2011-09-21 15:17:21 UTC
Created attachment 524228 [details]
Output of zif -v update

Description of problem:

Zif fails to properly install updates. Yum succeeds in resolving all deps and updates the packages properly.

Version-Release number of selected component (if applicable):

zif-tools-0.2.4-0.93.20110920git.fc15.x86_64
PackageKit-zif-0.6.17-1.fc15.libzif.so.3.x86_64
PackageKit-glib-0.6.17-1.fc15.libzif.so.3.x86_64
PackageKit-gstreamer-plugin-0.6.17-1.fc15.libzif.so.3.x86_64
PackageKit-yum-0.6.17-1.fc15.libzif.so.3.x86_64
PackageKit-0.6.17-1.fc15.libzif.so.3.x86_64
zif-0.2.4-0.93.20110920git.fc15.x86_64
PackageKit-yum-plugin-0.6.17-1.fc15.libzif.so.3.x86_64
PackageKit-qt-0.6.17-1.fc15.libzif.so.3.x86_64

How reproducible:

Always on this particular set of updates

Steps to Reproduce:
1. Run 'zif update' or start Kpackagekit with zif backend.
  
Actual results:

Nothing to do: no packages will be installed, removed or updated

Expected results:

Install updated packages

Additional info:

Comment 1 Kevin Kofler 2011-09-21 15:24:23 UTC
> Nothing to do: no packages will be installed, removed or updated
Uhm, the problem there is that there isn't anything to update to.

The fact that KPK reports this as a "dependency error" is bug #739985.

The other problem is, why doesn't it see anything to update to? Are you sure there's something to update to in the repositories you have enabled?

Comment 2 Kevin Kofler 2011-09-21 15:37:15 UTC
So the problem here is this:
> age of /var/cache/zif/x86_64/15/fedora-kde47/primary.sqlite is 92 hours (max-age is 168 hours)
> /var/cache/zif/x86_64/15/fedora-kde47/primary.sqlite uncompressed checksum correct (294f69d3bc2cbf79e86cda66395a56710895a5ed)

The default metadata expiry time of 7 days is just too long. (I personally set it to 30 minutes in my zif.conf. yum defaults to 90 minutes.) For some repositories (like the Fedora GA repository which should never change), it can make sense, but there the setting is overridden per repository. But for the default, no. Some repositories update much more often than once a week, and especially critical security updates must be installed in a more timely manner.

Comment 3 Richard Hughes 2011-09-21 15:45:22 UTC
The age is designed to be set in the thing calling libzif, so if you only have the GUI update check set for once per 3 days, then zif uses a max cache age of three days. 

You could argue that the default cache age for the zif _CLI_ needs to be lowered to once per day just for get-updates, and I think the system-wide default should be basically overridden by every UI that knows better. For me personally, I prefer a 7 day expiry as I rate my time more than incorrect results. Ideas welcome, as I'm aware there is no right answer here.

Comment 4 Kevin Kofler 2011-09-21 15:57:47 UTC
> The age is designed to be set in the thing calling libzif, so if you only have
> the GUI update check set for once per 3 days, then zif uses a max cache age of
> three days.

Is that actually implemented? Does PackageKit even know how often I have set KPackageKit to update (hourly in my case)?

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 ;-)

(IMHO, hourly checks in the GUI and 30-minute max cache age makes a lot of sense. Or generally 1/2 the check period.)

Comment 5 Richard Hughes 2011-09-21 16:31:43 UTC
(In reply to comment #4)
> > The age is designed to be set in the thing calling libzif, so if you only have
> > the GUI update check set for once per 3 days, then zif uses a max cache age of
> > three days.
> 
> Is that actually implemented? Does PackageKit even know how often I have set
> KPackageKit to update (hourly in my case)?

Sure, it's one of the hints that the front-end is meant to send, like the locale, background, active and that kind of thing. GPK certainly does but KPK might need the functionality adding.

> 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 ;-)

Valid point. Minus an hour sounds about right? if so, can you file another bug against PK please.

> (IMHO, hourly checks in the GUI and 30-minute max cache age makes a lot of
> sense. Or generally 1/2 the check period.)

The designers for GNOME3 wanted this to be _max_ once every day, and only showing non-security update popups max once a week. I think it's highly desktop dependent.

Comment 6 Richard Hughes 2011-09-21 16:33:37 UTC
commit 7563b7cb239f97dd184c62748ebb19cf61767284
Author: Richard Hughes <richard@hughsie.com>
Date:   Wed Sep 21 17:32:28 2011 +0100

    When getting updates set the maximum metadata timeout to be 24 hours
    
    Resolves https://bugzilla.redhat.com/show_bug.cgi?id=740305

If you want any smaller than 24h, just specify "-a 3600" on the command line. I think this is probably a good default.

Comment 7 Kevin Kofler 2011-09-21 16:42:47 UTC
> Sure, it's one of the hints that the front-end is meant to send, like the
> locale, background, active and that kind of thing. GPK certainly does but KPK
> might need the functionality adding.

I'll have to check, and file a bug against Apper/KPK at bugs.kde.org if it doesn't do it.

> Valid point. Minus an hour sounds about right? if so, can you file another bug
> against PK please.

Let's make it half an hour. KPK's minimum check time is hourly, and 1 hour minus 1 hour = 0, oops… I'll file a bug right now.

> The designers for GNOME3 wanted this to be _max_ once every day, and only
> showing non-security update popups max once a week. I think it's highly desktop
> dependent.

KPK allows setting it to hourly, daily, weekly, monthly or never. The default both upstream and in Fedora is daily. I personally set it to hourly on my machines. KPK does not distinguish between security and non-security for this: if it sees updates available when checking, it immediately offers them.

Comment 8 Kevin Kofler 2011-09-21 16:46:45 UTC
Bug 740331 filed against PackageKit.

Comment 9 Kevin Kofler 2011-09-21 22:28:24 UTC
> > Sure, it's one of the hints that the front-end is meant to send, like the
> > locale, background, active and that kind of thing. GPK certainly does but KPK
> > might need the functionality adding.
>
> I'll have to check, and file a bug against Apper/KPK at bugs.kde.org if it
> doesn't do it.

Looks like:
1. gnome-packagekit doesn't call pk_client_set_cache_age, only the gnome-settings-daemon "updates" plugin does. Shouldn't the gnome-packagekit app call this too?
2. There's no support for setting cache-age at all in packagekit-qt2, so this must be added to the lib before it can be added to Apper. (As for the stable KPackageKit 0.6.x which we still ship in Fedora, that one uses the old packagekit-qt, which doesn't support cache-age either.)


All this aside, I still think 7 days is a horribly bad default at the zif level. It's just too long. Reducing it to 1 day only for command-line update checks is not a good solution. I don't think you can expect all the other clients to override this. (Even your own gnome-packagekit doesn't, see point 1. above.)


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