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" <[email protected]> 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 >[email protected]. >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 [email protected]. 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.
