On Fri, Jan 17, 2014 at 2:10 PM, Manuel Wolfshant wolfy@nobugconsulting.ro wrote:
Whenever I've posed questions about holding updates to specific revisions, the answer has always been to 'mirror the repository' in the state you want.
The versionlock plugin exist for this purpose. But you are correct with the rest of your thoughts.
Versionlock only works on the local system. What I have always wanted is a way to test my local apps against 'current' system updates on one machine, then proceed to update a farm of machines to that same tested state even though newer versions may have subsequently been added to the update repositories - that is, the ability to reproduce an update.
With an assortment of application groups, OS revs, and a procedural requirement to not change all systems at once, needing a mirror of all update repositories in the state they were in when you tested each thing seems insanely inefficient. The SIG packages are likely to work like another layer with similar dependency. That is you won't really care about any specific versions, you just don't want the base-layer packages being pulled in an update until they have been tested against the SIG upper layer package that manages it. Either every SIG will have to have its own mirror of all updates that lags behind the real base/epel repos, or you need a way to tell yum which ones are OK. I don't think it is reasonable to expect everyone to work at the same speed - that is, you can't hold back base/EPEL packages until every SIG test passes.