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