On 03/12/2014 11:23 PM, Trevor Vaughan wrote: > > package_yum > package_gem > etc.... > > This would probably be pretty quick work overall and, of course, > eliminates all of the conflict issues. > > But....it doesn't feel like a good solution.
I agree that the implementation you sketched is messy, but the basic idea has actually occured to me as well when I read John's latest reply. The assumption that the regular old system will only ever use one provider for a given type holds true for many use cases. Package is a notable exception insofar as it can now be used to manage things that are not OS packages (but also gems and what have you). IMO the source of the issues here is that a gem is fundamentally a different kind of package than the rpm/deb/... your OS uses for native software. (So are CPAN modules, puppet modules etcpp.) Creating new types that explicitly name the type of package they deal with would handle this, yes (although I would vote that yum/apt/dpkg/rpm and friends stay in the pure "package" domain if we should ever go that route). It would be nice if we had a system were the compiler could infer the subtype from the value of the provider parameter. Because really, we are only prone to hit conflicts when non-OS packages are requested via providers like gem/cpan/pecl/pear/forge/whatever. The generic enhancement of the Model would allow to auto-switch to subtypes via arbitrary rules, where going by the provider value would likely suffice for the package type. Regards, Felix -- 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/53219896.6080206%40alumni.tu-berlin.de. For more options, visit https://groups.google.com/d/optout.
