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" -- fedora-test-list mailing list fedora-test-list@xxxxxxxxxx To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-test-list
