> This sounds like some big monitoring installation to me > where you certainly have other capacities (viz. like for developing > your own transports of check results). > Unfortunately, we haven't apart from intermediate Perl and passing C > experience in my case.
We wrote it all in Perl :-). > I guess the noop parameter in your code snippet is required to avoid > that the target platform's package provider is invoked > and instead the exec resource can take over? > I haven't found the noop parameter in the resource reference's package > section. > So is it one of the metaparameters that can be applied to (almost) any > resource (context permitting)? Yep: http://docs.reductivelabs.com/references/stable/metaparameter.html > Where best should I put my custom package resource? > Should it go in the main scope or better within my class'es scope? Something like: (where module_path is usually /etc/puppet/modules) Create a file: $module_path/my/manifests/package.pp With the contents: define my::package (...args...) { ... do stuff here ... } Will enable you to call it from anywhere: my::package{"foo": ensure => installed } And keep things in a neat name space for you. > Before I read your reply I came up with something more trivial in my > class definition > that most likely won't work: The rpm provider still won't pass --nodeps I think :-). ken. -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-us...@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.
