Yeah, after all this I think break out all of the subtypes, make the suitable but default the native *package* statement to whatever it does now.
Then...admins be careful! We can do some fanciness by mining the catalog when building the subtypes and making sure there is no conflicting native Package statement now that we have the fancy 'after everything' functions. Hopefully that makes sense, running on fumes. Thanks, Trevor On Thu, Mar 13, 2014 at 10:13 AM, Felix Frank < felix.fr...@alumni.tu-berlin.de> wrote: > > On Thu, Mar 13, 2014 at 9:23 AM, John Bollinger > > <john.bollin...@stjude.org <mailto:john.bollin...@stjude.org>> wrote: > > > That would work for me. Alternatively, there could be just one new > > > type, say SecondaryPackage, that rolled up gem, pip, fink, etc. > > On 03/13/2014 02:50 PM, Trevor Vaughan wrote: > > SecondaryPackage wouldn't fix it if you wanted to install using pip and > > gem on the same system. > > Huge +1. John, would you have us dance this one again in a year or two? ;-) > > > This gets hairy with RPM since Debian, etc... can > > all install and use the RPM command so I'm not sure quite how to handle > > that one. > > Ugh, that is a much better point than I'd like to admit. > > It could be handled by the "pick subtype based on provider value" rule I > sketched earlier, if we opt to *not* let dpkg, rpm and friends remain > un-subtyped. > > It's not even that much of an outer edge case, because given a Debian > box on which you want/have to use this RPM from Corporate IT, this would > be a likely manifest: > > package { > "puppet": provider => "dpkg", ensure => absent; > "puppet": provider => "rpm", ensure => present; > } > > And yes, specifying that the rpm should require the dpkg would be hella > non-intuitive (require Package["puppet:dpkg"]? Dpkg_package["puppet"]? > Code readability anyone?) In that vein, it would indeed be helpful to > allow the alternative syntax of > > dpkg_package { "puppet": } vs. rpm_package { "puppet": } > > ...but that will introduce new pitfalls for users, I believe. Full > vicious circle. > > 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/5321BD0F.5090507%40alumni.tu-berlin.de > . > For more options, visit https://groups.google.com/d/optout. > -- Trevor Vaughan Vice President, Onyx Point, Inc (410) 541-6699 tvaug...@onyxpoint.com -- This account not approved for unencrypted proprietary information -- -- 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/CANs%2BFoXhueuJgXqa0fiODX0qPJo4pzu8%3DFNCWQu9LFKR_RHBLw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
