Bug 155946 - RFE: automated downloading and caching of package updates to local disk to speed up actual user initiated updating
RFE: automated downloading and caching of package updates to local disk to sp...
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: PackageKit (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Robin Norwood
Fedora Extras Quality Assurance
: FutureFeature
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-04-25 19:00 EDT by Jef Spaleta
Modified: 2008-08-18 05:01 EDT (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-08-18 05:01:09 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Jef Spaleta 2005-04-25 19:00:18 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
Comment 1 Warren Togami 2005-09-17 18:20:09 EDT
> 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.
Comment 2 Jon Stanley 2008-04-23 16:29:45 EDT
Adding FutureFeature keyword to RFE's.
Comment 3 Jon Stanley 2008-05-12 15:29:04 EDT
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.

Comment 4 Bill Nottingham 2008-05-12 15:50:43 EDT
PK has an option to do something like this, IIRC. Assigning there, in any case.
Comment 5 Richard Hughes 2008-08-18 05:01:09 EDT
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.

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