Wow - I never knew about ensure_packages. I'm not sure if I overlooked it or if it's relatively new, but either way, I agree that it should be more widely used.
I run into the same issue that you described when using third-party modules. I try to avoid this in my own modules by only managing packages that are core to the module and expect the user to manage secondary packages on their own. Unfortunately this method imposes more responsibility onto the user. ensure_packages might be a good solution to this. On Tue, May 21, 2013 at 11:27 AM, Jonathan Proulx <j...@jonproulx.com> wrote: > One of the most frustrating things about puppet is duplicate definitions > of packages, > > The "ensure_packages" function from stdlib seems very much like the > correct way to handle this: > > newfunction(:ensure_packages, :type => :statement, :doc => <<-EOS > Takes a list of packages and only installs them if they don't already > exist. > EOS > ) do |arguments| > > Why isn't this a core feature? Or better why aren't resources that are > identical merged? Clearly there is a conflict if they are defined with > different parameter (ensure => installed -vs ensure => latest for example) > but if they are really identical where is the conflict? > > My current situation is that we define parted and xfsprogs in our local > site configs and the enovance ceph modules also do so. Both of these seem > reasonable to me as we need them to make all our systems go and the ceph > module needs them to set up the object storage volumes (which is it's > primary function) and can't assume everyone uses parted and xfs. > > The two prevailing opinions in my web readings seem to be to use Virtual > resources which is fine for local modules but not so good for sharing and > the purist opinion that if there is a conflict the conflicting parts should > be split out into an independent module, which is fine for large functional > chunks like httpd but ridiculous for single utilities that require no > configuration. > > Yet there is little discussion of ensure_packages as an alternative. Is > this for cause or just because it is not well known? > > -Jon > > -- > You received this message because you are subscribed to the Google Groups > "Puppet Users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to puppet-users+unsubscr...@googlegroups.com. > To post to this group, send email to puppet-users@googlegroups.com. > Visit this group at http://groups.google.com/group/puppet-users?hl=en. > For more options, visit https://groups.google.com/groups/opt_out. > > > -- Joe Topjian Systems Architect Cybera Inc. www.cybera.ca Cybera is a not-for-profit organization that works to spur and support innovation, for the economic benefit of Alberta, through the use of cyberinfrastructure. -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
