"yum update" with most of the rpms already on a USB key?

[Rodd Clarkson]

On Mon, 2009-03-02 at 11:35 -0800, Mike Cloaked wrote:
> 
> 
> Mike Cloaked wrote:
> > 
> > 
> > I do this all the time - in fact I update one F10 machine here and then
> > rsync the rpms to my other f10 machines locally - then yum -y update on
> > any of the other machines usually only has the odd additional update that
> > yum grabs from the repos externally - yum knows that if the rpm is already
> > in the cache it does not need to download it but if the correct rpm is not
> > there for a package it then looks in the defined repos - in other works
> > yum is much cleverer than you think!
> > 
> 
> By the way what I do is to rsync /var/cache/yum/updates/packages and the
> corresponding packages for the other repos I use such as rpmfusion, fedora,
> updates-testing etc. I don't rsync the metadata - that way the metadata gets
> downloaded when yum runs, and then yum decides what is needed or not in the
> way of downloads for the current system.

I can't help but wonder whether a useful feature on yum wouldn't be to
have an option for one of the boxed in the local network to become a
'repo' of sorts.

I'm not suggesting that it needs to be a fully equiped repo, but jsut
somewhere where all machines would look for packages before going
offsight to other servers.

SO, as an example.  If I have a number of local installs of Fedora, I
could install a server package that makes that machine a local repo.
This could maybe be advertised over the local net using some zeroconf
setting or something (might be a pipe dream) and of course you could set
up the repo files manually too, but the zeroconf thing would be a nice
Just Works option.  Obviously, package on the server wouldn't be removed
until a more recent package is installed.

When local machines do a yum update, that server would then become a
conduit for the updates.  Instead of the local machine checking for new
update information, that server would do it and then hand on the current
information.  And the server would download all needed packages.

So from a user perspective it would work like this.

Joe installed a number fedora installs on his network.

He nominates a single box as the 'local repo' and then installs the
local-repo software and enables it.

Then on box1 (another box on the network) he runs 'yum update'.
zeroconf (or whatever it's called) tells box1 that there is a localrepo,
so it asks the local repo for a list of updates.

localrepo checks for updates and then hands box1 the list (metadata??)

box1 one tells localrepo that its pkg1 - pkg10 and localrepo downloads
these packages, stores them and passes them on to box1 (which then
finishes it's yum update)

box2 runs yum update and localrepo checks for any updates.  There are
none, so it hands over the old update list.  box2 needs some of the
updates that box1 needed, along with pkg11-pkg15, so localrepo downloads
these extra packages and hands over what box2 needs.

box3 runs yum update and localrepo checks for any updates.  There's a
new list of updates so it grabs the list and hands it to box3.  box3
only needs package already supplied, except pkg5 has been updated so
localrepo downloads pkg5.1 and hands over what box3 needs.

etc.

The big advantages to this sort of system is that you massively minimise
downloads for a multiple fedora installed environment.

The localrepo only gets what packages are needed by the local install
(instead of having a cache of all the possible packages).  And it only
maintains the list of need packages when requested (instead of having to
update all the changes).

And boxes on the network aren't pulling the same packages off remote
servers again and again and again.

It should also be pretty simple for anyone to use.  Install a package.
Start a service.  Enable some firewall settings (zeroconf) or install
some .repo files (which the localrepo software can autogenerate for the
admin).  After this yum just works like normal as far as the end user is
concerned (except that a lot of the downloading will be a lot faster
too).


Thoughts


R.



-- 
"It's a fine line between denial and faith.
 It's much better on my side"