Les Mikesell wrote:
>>I want that functionality, but I was arguing that all it would take to
>>get it is sequentially increasing timestamps on files being added to
>>the repository and knowledge of the final timestamp of each consistent
>>update set - and letting the yum client have that information to figure
>>out the rest.
>>
>>
I suspect that a simple time-stamp freeze wouldn't be sufficient. It is
a good start. Knowing that what you tested, certified and are rolling
out will stay as a constant is a good thing. Achievable today when you
control your own rep. However, the problem of configuration management
gets more complex quickly when you may want to add additional freezes on
different branches.
For example - your developers have a dependency on App X @ v2-2-3.4.5
(Sept 4 2005) and library Y @ v16.4-5 (Aug 11 2005). You need to freeze
that app and that library, but may be ok with, or want, a security fix
on App Z released Sept 13, 2005 (Again achievable with your own rep). It
gets plain ugly when your developers (or app owners) want incompatible
freezes (lib v3.4 for Bob & lib v5.1 for Sue).
regards Dave
www.hornfordassociates.com
