Separate types undoes basically what "package" now tries to make as transparent as possible. I guess a case could be made to have "package" only deal with the OS native package provider and have separate types and providers for "secondary" packages like gem, wheel/egg/whatever etc.
On Tuesday, 7 October 2014 12:39:13 UTC-7, Trevor Vaughan wrote: > > I'm still a fan of separate types. > > Just put a nail in the coffin once and for all since this is really the > only type which tries to get fancy. > > Trevor > > On Tue, Oct 7, 2014 at 3:27 PM, John Bollinger <[email protected] > <javascript:>> wrote: > >> >> >> On Monday, October 6, 2014 5:13:43 PM UTC-5, Andy Parker wrote: >>> >>> Sorry to resurrect an old thread, but this came to my attention again >>> today. >>> >>> On Fri, Mar 14, 2014 at 6:20 AM, John Bollinger <[email protected]> >>> wrote: >>> >>>> >>>> >>>> On Thursday, March 13, 2014 8:50:19 AM UTC-5, Trevor Vaughan wrote: >>>>> >>>>> SecondaryPackage wouldn't fix it if you wanted to install using pip >>>>> and gem on the same system. >>>>> >>>>> >>>> >>>> I see I should have devoted more text to my last statement: "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." If the >>>> type's name were a composite of type (gem, pip, etc.) and name within that >>>> type, then it very well could support different package types all in one >>>> resource type. I suppose the individual package types could be features. >>>> Whereas such an approach cannot work for Package, it would be eminently >>>> workable for a unified SecondaryPackage type. >>>> >>>> Putting it all in one type might make it a bit easier to convert >>>> existing manifests, and it would give users a single place to look for >>>> support for this sort of thing. On the other hand, the provider(s) would >>>> have to support multiple (secondary) package types. It's a trade-off >>>> between what aspects must be complicated and what parts can be simple. >>>> >>>> >>> I think there might be a much simpler solution to the entire thing. I >>> noticed that all of the error messages that I've seen about this are about >>> being unable to alias. What seems to be happening is that since the "name" >>> parameter of a package resource is the namevar, the system is automatically >>> creating an alias for the package resource using the name. That means that >>> we have both a Package[title] reference and a Package[name] reference. The >>> same thing occurred in the comment that was recently added to the ticket >>> about the tidy type. >>> >>> So here is my proposal: just remove the automatic aliasing. That means >>> that the only way to reference a resource is via the title or an explicit >>> alias. I tried this out on a VM by simply commenting out one line ( >>> https://github.com/puppetlabs/puppet/blob/master/ >>> lib/puppet/resource/catalog.rb#L90) and it seemed to work wonders. >>> >>> Why not just go with that change? Am I missing something? >>> >> >> >> The main issue is *name* (not necessarily title or alias) collisions. >> If you want to manage an RPM named 'ntp' and also a gem named 'ntp' on the >> same system then you are hosed. The two resources have the same unique >> identifier ('ntp') which you pretty much have to use to map correctly to >> the physical resource. If you give up on requiring uniqueness of >> resources' natural unique identifiers then you throw in the towel >> altogether on avoiding duplicate resources. >> >> The two names in my example actually live in different namespaces, but >> those namespaces map to resource providers, which traditionally are not >> specified in manifests nor known during catalog building, except for >> packages that are expected or known in advance to be supported by a >> "secondary" package provider. If this is a problem that's going to be >> solved then I still like the SecondaryPackage resource type for that task, >> or perhaps even separate Gem, etc. types. >> >> >> 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 [email protected] <javascript:>. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/puppet-dev/90cc269a-13c4-4736-99a8-c3c81bd94d1e%40googlegroups.com >> >> <https://groups.google.com/d/msgid/puppet-dev/90cc269a-13c4-4736-99a8-c3c81bd94d1e%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> >> For more options, visit https://groups.google.com/d/optout. >> > > > > -- > Trevor Vaughan > Vice President, Onyx Point, Inc > (410) 541-6699 > [email protected] <javascript:> > > -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/a9e37f89-3cc3-4c3e-a989-116b26317da5%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
