Issue #4113 has been updated by Pablo Fernandez.
Jo Rhett wrote: > I agree, but you guys are refusing to implement simple, good, working things > because you want to do it right -- but then you aren't doing it right either. > I understand that doing it right takes some time. I don't understand why we > can't get the simple things (which would work for most people) into place > quickly. I absolutely agree with your statement. Optimally, there would be a "repo" type, that covers all cases (including windows!) and not a yumrepo. But some times implementation drives design, like now. Package and Yumrepo are tightly related, even if you want to keep them separate. And package names are some times generic, but other times are distribution-based... at the end is a task for the sysadmin to do the right thing: type the right package name, the right yumrepo, and the right parameters for yum (but this last part is missing). I don't see why you want to write a wrapper for yum. If there is an error in the parameter, yum will fail, and we will get a notice. But if you don't want to add any parameters to yum, then **please add at least the enable_repo and disable_repo**. They are extremely important to control the source of your package, since you may have different local and/or remote repositories. This is a very big deficiency!! ---------------------------------------- Feature #4113: Allow provider-specific options as a first class part of the RAL model. https://projects.puppetlabs.com/issues/4113#change-77750 Author: Oliver Hookins Status: Accepted Priority: Normal Assignee: Category: Target version: 3.x Affected Puppet version: 0.25.5 Keywords: Branch: http://groups.google.com/group/puppet-users/browse_thread/thread/2ef615fc42225d99?pli=1 Our requirement is more or less the same as in the linked thread, we need to use a proxy to install gems but for a variety of reasons can't set a global proxy on the machines. Thus some way of passing options to gem is necessary. (Nigel) - We should do this consistently across providers, perhaps combining with the "preseed" functionality of apt/dpkg. Rather than doing this as a generic "pass unstructured data" hack, we should resolve this by allowing provider-specific parameters to be first class elements in declarations: <pre> package { example: provider => something, something_specific_parameter => value } </pre> That should cover more than just packages - extending to all types. Requiring the provider to be explicitly specified is preferable to allowing it to be inferred when non-type parameters or properties are present. It is unclear if both properties and parameters should be supported, or if only parameters should be allowed. -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://projects.puppetlabs.com/my/account -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en.
