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 <john.bollin...@stjude.org>
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?


>
> 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 puppet-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/puppet-dev/3c52ca61-15b1-48e7-a694-c3fafd70b11c%40googlegroups.com
> <https://groups.google.com/d/msgid/puppet-dev/3c52ca61-15b1-48e7-a694-c3fafd70b11c%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Andrew Parker
a...@puppetlabs.com
Freenode: zaphod42
Twitter: @aparker42
Software Developer

*Join us at **PuppetConf 2014, **September 20-24 in San Francisco - *
www.puppetconf.com

-- 
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/CANhgQXtardhP4jCc-35G8QG36h4%2BUE53GLAoVpVXRSXP7remJQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to