James wrote:
Regarding adopting a specific set of package versions -- I am normally concerned only with getting "up-to-date" (i.e., "latest") packages when I do 'yum upgrade <package-name>'. But if I *needed* a specific version, I would use 'yumdownloader <package-version>' and then use 'rpm' (+ appropriate flags) to explicitly install it.
Yes, your needs are unlike the childrens' needs. ;-)
Whoa !! I can understand the usefulness to a _school administrator_ for all the systems he is responsible for to have identical software. [And a developer may want to perform tests on a system that has *exactly* the same software as another person's.] But why ought __children__ all have identical versions (e.g., bash-4.0-7) on their systems ? Whatever happened to the idea that children ought to be able to re-program their systems (or to add software from friends, etc.) -- wouldn't that make their XO *different* from that of other children, even if it started out with the same image ?
A new method being proposed is a yum update. This was not used previously because it did not produce an identical filesystem to a particular image version, and it could not be anchored to a particular image version, it could only be updated to the latest version of all packages. Therefore it was not a test of an image, but rather a test of the latest version of all packages.
So, how can you simply ensure that yum update will adopt a specific set of versions that match the build that was done?
As I said in what you quoted: don't rely completely on an automated 'yum upgrade'. Rather, use a manual 'yumdownloader' followed by 'rpm' for where you want a specific version of a package.
[Let me suggest that persons subject to download limits are not the best candidates to call upon to perform 'test of an image'. I believe the original idea was that the school would pay for fetching the image -- then the children would perform updating from local resources, without themselves incurring internet download costs.]
mikus