Red Hat Bugzilla – Bug 155946
RFE: automated downloading and caching of package updates to local disk to speed up actual user initiated updating
Last modified: 2008-08-18 05:01:09 EDT
Opened on warren's request.
Description of general idea:
Find a way to use idle bandwidth to cache updates locally, so that when a user
initiated update activity occurs the update can happen quickly from the locally
cached package instead of having to go hit the network on demand.
Constraints/features in no particular order of importance:
will need to be able to throttle this service based on other network activity.
You want to restrict this to using idle bandwidth if you can and prevent
disruption of normal network activity. Update caching should never ever get in
the way of downloading teletubby video clips.
You'll have to add some clock randomization to make sure all the clients in a
timezone don't all hit mirrors at the same time pulling downloads. Every hour +
random(0-30) minutes to spread out the client attempts maybe.
How about we hide this from anacron completely if possible.
Going to have to have a way to setup a predefined amount of local disk space to
use, and an algorithm to purge old cached updates as needed.
Will want to be able to distinguish the auto downloaded packages from packages
downloaded by user action. One way is to have this automated download and purge
cache area seperate from the existing yum cache or up2date spool area.
The yum and up2date cache areas are used by some users to hold fallback packages
in case installed updates are sour. You do not want an automated download/purge
service purging fallback packages that users are trying to keep as a safety net.
As updates are pulled from the auto download cache area they move into the
traditional yum/up2date cache area. This however will require updating of
existing tools like yum and up2date to see a 2nd cache area.
-jef"it must be written in ruby"spaleta
> restrict this to using idle bandwidth
This is *hard* because you don't know what the rest of the network is doing.
I think perhaps you would want the user to opt-in to background downloading like
Windows XP gives users the option. There would also need to be a default
threshold of free disk space where it will avoid downloading stuff in order to
prevent completely filling up the disk.
> purge cache area seperate from the existing yum cache or up2date spool area.
I don't think using a separate download area for this makes any sense.
Adding FutureFeature keyword to RFE's.
Do we still want to do this? I know that this comes up from time to time, and I
also think that it needs to be opt-in if we do it.
PK has an option to do something like this, IIRC. Assigning there, in any case.
I don't think PK should second guess the user more than it does already. I don't want Graham (http://packagekit.org/pk-profiles.html) to have the Internet "slow down" for no reason, nor for the computer to start doing too much work when idle as ideally we should be powersaving.