That's the fundamental issue though.
Package isn't a package. Package is one of many distinct things.
This is like the following:
user { 'foo': provider => 'passwd' }
user { 'foo': provider => 'apache' }
They're simply two different things so they would be user (i.e. native
user) and apache_user (i.e. apache user).
We have:
package { 'foo': provider => 'native (yum, rpm, deb, whatever)' }
package { 'foo': provider => 'gem' }
These are NOT the same thing. One is a native package and one is "something
else" and I believe that they should just be separate because they're
"native" and "not native".
Trevor
On Tue, Oct 7, 2014 at 10:10 PM, Daniele Sluijters <
[email protected]> wrote:
> 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]>
>> 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/a9e37f89-3cc3-4c3e-a989-116b26317da5%40googlegroups.com
> <https://groups.google.com/d/msgid/puppet-dev/a9e37f89-3cc3-4c3e-a989-116b26317da5%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%2BFoV2GVrdEk5YfLQAVCu32TvfxONTL42eWL6wOofwOmtJkg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
