To me it sounds like you need to make a design decision: Either you care enough about these potential version differences to go through all the trouble to manage them properly, or you don't. Both are fine, personally I feel that the small chances that dependent packages have different versions installed with one having more bugs then the other is so negligible that it doesn't warrant the time investment needed to manage all those dependencies.
my 2 cents :) Walter On Tue, Dec 11, 2012 at 1:10 PM, James Gray <james.g...@stillidream.org>wrote: > On 11 December 2012 11:33, David Schmitt <da...@dasz.at> wrote: > > > > You'll have to start managing versions. One way or the other. Client side > > there's apt's pinning, yum probably has some plugin to do so. Server side > > you can use a custom repo or puppet packages's ensure => version. > > I don't think this is workable for the reasons I have described. It's > not realistic to list packages and versions of everything on my system > and keep them up to date etc. > > > For any significant amount of machines and packages, you'll really want > to > > look into hosting that repo yourself. That way you can > > > > * stage security and other updates > > * keep most control over package versions with the least > > per-node overhead > > * keep installs repeatable > > Sure but the problem I have described is with even small > infrastructures where you don't want to maintain anymore than you have > too. If you just have a web server and a database server, you don't > want to setup a repository too just (and make sure it's > monitored/always available/update to date) etc. It is also not clear > to me how you'd manage the process of pulling security fixes into your > repository from upstream. > > I should say this is on EC2 and so another solution would be just to > use AMI's I guess. Maybe building the AMI's with Puppet. > > Thanks, > James > > -- > You received this message because you are subscribed to the Google Groups > "Puppet Users" group. > To post to this group, send email to puppet-users@googlegroups.com. > To unsubscribe from this group, send email to > puppet-users+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/puppet-users?hl=en. > > -- Walter Heck -- Check out my startup: Puppet training and consulting @ http://www.olindata.com Follow @olindata on Twitter and/or 'Like' our Facebook page at http://www.facebook.com/olindata -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
