Requires Free Membership to View
When you register, my team of editors will also send you resources covering Linux administration and management; integration and interoperability between Linux, Windows and Unix; securing Linux and mixed-platform environments; and migrating to Linux.
Margie Semilof, Editorial Director
Looking at the home page, http://linux.duke.edu/projects/yum/, I think my memory started working again. The main problem with straightforward use of the rpm tool (at least the older versions I've played with) is this: The package you have at hand may depend on other packages that you don't have at hand. Plain rpm doesn't help you with this problem beyond reporting that specific dependancies exist. You have to go and fetch those other packages yourself, and then call rpm again. Second-generation package installers automate the retrieval and install of dependant packages, so that you get a "cascade" effect. If you install one package, everything else required is dragged in too. It's a little like cascaded updates in a relational database. Beyond that, I haven't played with yum.
The benefit of these newer systems is that you can think less -- the tool imports a flock of updates everytime you use it. The downside is that you lose a little control over the patch level of your host -- you have to operate at a higher level and keep track of everything you tell yum to do. You have to trust yum to keep the patch level of the host sanely arranged, because you can't control the system at the level of a single RPM anymore.
According to the yum docs, you can run yum with packages sourced from a central repository. So you should be able to drag down newly released packages to one spot, and then by running yum on each host, the same flow of patches should be sent to each host from that spot. Standardised and semi-automated patching.
This was first published in June 2004
Join the conversationComment
Share
Comments
Results
Contribute to the conversation