Augmented cache control for PreIndexed sources.

In addition to better behavior when WinGet cannot refresh the cache, some users would prefer greater control of what to do in the event the cache is stale.

WinGet currently does have a TTL setting for the default SLA of the cache, but maybe there is a need for even more explicit control.

Users can run winget source update to force a cache update (assuming the network is functioning correctly), but there is no notion if running a command and explicitly avoiding the cache refresh.

From:

• #5834

@lkrms we have been discussing the logic used on a retry and the best way to proceed if we can't fetch an updated cache. In one case if we're not able to get the "initial" cache, it would be a complete failure. In the event of a stale cache we could proceed with that stale cache and some kind of informational message about how old the cache is.

It makes sense for winget to keep its cache in sync transparently; I'm coming at it from a Linux package management angle (I've already mentioned pacman, but apt and others are similar), where in the absence of optional tooling, the cache isn't refreshed from upstream unless you explicitly request it.

I'm not suggesting winget should do likewise--it's a different beast with a different audience--but the case for allowing users to "sync" and "install" as distinct operations if they choose to is arguably stronger for winget than for a typical Linux package manager, simply because its cache is, by definition, decoupled from the hosting platform of basically every package it services.

If I can't sync my pacman cache, I can't install packages either, because they all come from the same place; but winget doesn't suffer from this constraint 🙂. Its default behaviour when the cache is unreachable is important to get right, especially when you factor in bootstrapping scenarios, but perhaps it could be left as-is, albeit with improvements to how the failure is communicated to end-users. If a --no-sync option (and/or a no-implicit-cache-sync setting) were available, it could be suggested as a way to mitigate the issue temporarily, for example. And for users who would always enable --no-sync, I guess you'd need a standalone sync command. Best of both worlds?

Originally posted by @lkrms in #5834

Start by reviewing the linked discussion in #5834 and the existing winget source update behavior. Clarify whether the desired scope is --no-sync, a no-implicit-cache-sync setting, a standalone sync command, or improved stale-cache messaging; done requires an agreed design and documented behavior for refresh failures and stale caches.