I am kind of interested in what you describe. I think for our environment, keeping the package type as is and creating a new ³gem² type that inherits from package would be just fine. If we only consider RHEL-based systems for a moment, is there really a possible conflict scenario other than yum/rpm and gems (where you wouldn¹t be insane for trying to install multiple packages of the same name)?
It would still be nice to see some work go into the RAL for Puppet 4 and have a permanent solution. However, would it be easier in Puppet3 if someone just created a ³gem² module that had the inherited type/provider in it? It would be trivial to do that. Drew On 3/13/14, 6:37 AM, "Felix Frank" <felix.fr...@alumni.tu-berlin.de> wrote: >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 a topic in the >Google Groups "Puppet Developers" group. >To unsubscribe from this topic, visit >https://groups.google.com/d/topic/puppet-dev/LatVZFUkwEM/unsubscribe. >To unsubscribe from this group and all its topics, 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. -- 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/CF470C6D.14D64%25drew.blessing%40buckle.com. For more options, visit https://groups.google.com/d/optout.
