On Thursday, March 13, 2014 8:02:22 AM UTC-5, Trevor Vaughan wrote:
>
> Looking at the list of providers for file, on RHEL systems you'll probably
> only run into conflicts with *native* (yum, rpm, up2date), pip, and gem.
>
> I also am not opposed to this. As far as I can tell, 'package' is the only
> type that doesn't follow the rules of the other types (manage one thing and
> manage it well). It rolls lots of different things under the same abstract
> header.
>
>
Exactly so. If there is a design flaw here, it is that the meaning of the
Package type is fuzzy. It *should* represent software packages for the
target node's native package management system.
> Frankly, if I have to specify provider => 'gem', that's not any more work
> than specifying gem { 'name': ... } and the latter is a lot clearer in
> terms of dependency maintenance.
>
> So, +1 from me for just creating a bunch of new types.
>
>
That would work for me. Alternatively, there could be just one new type,
say SecondaryPackage, that rolled up gem, pip, fink, etc.. The trick here
would be that the provider(s) must not be based on package type, so that
the package type could be used as part of a composite name.
John
--
You received this message because you are subscribed to the Google Groups
"Puppet Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-dev/67e90ed8-a8af-4e3a-a02b-f8f2e2ee035a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
