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]> 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]. > 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] -- 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/CANs%2BFoXqt6-h7rgV_F2mOti_RSYXW8my8RmgjzO5%2B%3DfW8Gvu9g%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
