On Fri, Sep 01, 2006 at 10:10:45AM -0400, Tim Forbes wrote: > On Fri, Sep 01, 2006 at 08:27:14AM -0500, Les Mikesell wrote: > > On Fri, 2006-09-01 at 01:06, Panu Matilainen wrote: > > > > > > > >> Reproducing an installation starts to approach a valid reason :) However > > > >> build and file time stamps are not reliable way of doing this, nothing > > > >> guarantees that packages arrive in a given repository in the order they > > > >> are built: for example the vendor might have a heavier testing programme > > > >> for the kernel than some minor package, causing kernel to arrive in the > > > >> repo much later than some other package despite having an older timestamp. > > > >> > > > >> If you want reproducable installations, use versionlock (plugin > > > >> available in yum-utils) on the packageset you tested and forget about > > > >> timestamps. > > > > > > > > Is there documentation available for the various plugins and how > > > > to use them together? For example, given a tested system, how > > > > would you tell a box in a different location to update/install > > > > to the same packages and versions? > > > > > > You can set the versionlock file to be somewhere remote, eg > > > locklist=http://my.main.server.com/versionlock/distro/$releasever or > > > similar. Then you just control that one file, all yum update/install > > > operations will use the versions specified there no matter what other > > > versions are available. > > > > I hate to sound dense, but I don't see how that follows the > > tested system. Can you give a complete example or point to > > more detailed documentation? The scenario is that one machine > > is used for testing and once it is approved, the same set > > of packages should be updated on a group of remote machines > > in different locations. However, one or a few RPM packages will > > be local system config files that are tied to the machine > > location and should not be identical everywhere. > > > > > > Also, now that the download-only option has been moved out of yum > > > > itself, how do you tell it to pre-fetch the packages you are going to > > > > need (either for this or a normal 'update'), so as to be able to plan > > > > the timing of the actual package installation/updates in a way not tied > > > > to internet bandwidth or health of remote repositories? > > > > > > One way to do "download only" with current yum itself is to set > > > tsflags=test in yum.conf, that way it'll just perform a transaction test > > > but not actually do anything to the system. Or you can write a five-line > > > plugin to make it stop once download completes. > > > > Again, how is someone supposed to know how to do this? Do you > > now have to know python to interact with yum beyond the default > > 'I hope the repository is OK' mode? > > Les, yum actually helps you solve the issue. I hunted on the internet a bit > and deduced that it should be pretty easy to get going. On my FC5 box... > > [root@tforbes-88 ~]# yum install yum-downloadonly > [root@tforbes-88 ~]# yum > Loading "downloadonly" plugin > etc > > Disable the feature by editing the following file like this... > [root@tforbes-88 ~]# cat /etc/yum/pluginconf.d/downloadonly.conf > [main] > enabled=0 Sorry to be responding to my own answer, but I have just discovered a crutial point. After making the plugin available and enabled, you must use the --downloadonly option when starting yum. Here are the steps I used to separately download and install a package... [root@tforbes-88 etc]# yum --downloadonly update vixie-cron [root@tforbes-88 etc]# yum -C update vixie-cron > > > > > > > -- > > Les Mikesell > > lesmikesell@xxxxxxxxx > > > > _______________________________________________ > > Yum mailing list > > Yum@xxxxxxxxxxxxxxxxxxxx > > https://lists.dulug.duke.edu/mailman/listinfo/yum > > -- > timforbes(at)canada(dot)com > tforbes(at)greenbullfrog(dot)com > tf(at)greenbullfrog(dot)com > _______________________________________________ > Yum mailing list > Yum@xxxxxxxxxxxxxxxxxxxx > https://lists.dulug.duke.edu/mailman/listinfo/yum -- timforbes(at)canada(dot)com tforbes(at)greenbullfrog(dot)com tf(at)greenbullfrog(dot)com
