[CentOS-devel] Repository structures for SIG and variants in the future

[Les Mikesell]

On Fri, Jan 17, 2014 at 2:10 PM, Manuel Wolfshant
<wolfy at 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.

-- 
    Les Mikesell
      lesmikesell at gmail.com