Re: download strategy, was Re: apt, yum, up2date, smartpm, ... ?

On Wed, 2005-09-21 at 21:14, William Stearns wrote:
> >>
> >> - place any files you already have in the tree in advance so they're not
> >> downloaded again
> >
> > Is there an automated way to do this for the base distribution or
> > pretend you've done it by loopback mounting the distribution
> > iso images?
> 
>  	The question we're trying to address is how to handle low 
> bandwidth lines efficiently; people with this problem are less likely to 
> have access to the iso images for these distributions.

If they are really poorly connected, I'd expect them to have
the Cheap Bytes or equivalent CD's.  If the connection is
so-so 'rsync -P ...' will eventually get a iso and it
can be restarted nightly as needed.

>  	In the cases where the user does have access to the iso images, 
> the files can be copied over with any file management tool.  Loopback 
> mounting the images means you still use the space for the iso files, but 
> saves about $4 of disk space by not copying the rpms.
>  	If that's important to you, yam does allow loopback mounts of iso 
> images.  yum-pull is able to use loopback mounted files, it just doesn't 
> do the mounting and symlinks.

I'd need 4 or 5 of these at any one time to cover
different distributions and versions I might have at a
location.  The disk space is irrelevant compared to the
time setting it up. Can't the whole mess be automated?

> > This doesn't work for repositories that use the mirrorlist option. Yum
> > picks something different from the list every time, cluttering the
> > cache and defeating its purpose.
> 
>  	Good point; I hadn't thought of that.  You'd have to put in a 
> restricted list of mirrors to have this help at all, and cut down to 1 
> mirror to get full use of the cache.

Again, can it do the right thing automatically?  It seems odd
that the repository setup goes out of its way to defeat
normal caching.

> > yum --download-only ... &
> > so yum could decide what it needs and get it in the background or
> > as a scheduled command - and this needs to report it's status so
> > you know whether or not everything is available for the subsequent
> > real yum action.
> 
>  	Good approach.
>  	One minor detail is that the --download-only option was removed 
> from recent versions of yum.  Having one machine do its download in the 
> middle of the night would pull down the files the other machines would 
> later need.  You could even nfs mount the lead machine's /var/cache/yum 
> over to the other hosts and run them with "yum -C".

But knowing what files to download is the main thing that yum
gets right and can't be helped by external tools.  I suppose
on some machines you could let it run and hope something
works.

-- 
  Les Mikesell
    [email protected]