Bug 740305

> 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?

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.

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.

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

(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.

commit 7563b7cb239f97dd184c62748ebb19cf61767284
Author: Richard Hughes <richard>
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.

> 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.

Bug 740331 filed against PackageKit.

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