Les Mikesell wrote:
Getting a bit off the original topic here, but the "other" thing I've always wished yum could do is "repeatable" updates. That is, the ability to update one machine, test some things, then update another and get only the same set of changes even if some newer packages had been subsequently added to the repos.
To me, that isn't functionality for the client, it is functionality for the server / cache. It is a feature of WSUS - the ability to approve updates and only allow clients to "see" the approved ones and not any other.
Right now, there isn't a lot of intelligence built into the server end ( MirrorManager excepted ) of the update process. The repositories serve static files, that's it. Fedora can't ask any more from mirrors. If in your environment you want to control how clients get updated, then it makes sense to me that centralized control from the server side and keeping the client side "dumb" is better. You only have to distribute the repo configuration to use the controlled repo once, instead of distributing specific update lists continually.
That control is one of the reasons why as an admin I am interested in InstantMirror and this discussion.
Charles Dostale
chasd wrote:
Getting a bit off the original topic here, but the "other" thing I've always wished yum could do is "repeatable" updates. That is, the ability to update one machine, test some things, then update another and get only the same set of changes even if some newer packages had been subsequently added to the repos.
To me, that isn't functionality for the client, it is functionality for the server / cache. It is a feature of WSUS - the ability to approve updates and only allow clients to "see" the approved ones and not any other.
Right now, there isn't a lot of intelligence built into the server end ( MirrorManager excepted ) of the update process. The repositories serve static files, that's it. Fedora can't ask any more from mirrors. If in your environment you want to control how clients get updated, then it makes sense to me that centralized control from the server side and keeping the client side "dumb" is better. You only have to distribute the repo configuration to use the controlled repo once, instead of distributing specific update lists continually.
That control is one of the reasons why as an admin I am interested in InstantMirror and this discussion.
I was thinking that if the client were aware of all the packages in the repo, all you'd need is a timestamp or some sort of transaction id associating the last rebuild of repo data with the packages added then. That way you could tell the client the timestamp or latest id that you wanted it to duplicate, and it could just ignore any packages newer than that. I think the client normally only sees repo data for the latest version of each package that is available - but there must be some way to get the dependency info for older ones, given the ability to request them specifically.
-
chasd -
Les Mikesell