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 <john.bo...@stjude.org
> <javascript:>> 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 puppet-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-dev/90cc269a-13c4-4736-99a8-c3c81bd94d1e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
