SecondaryPackage wouldn't fix it if you wanted to install using pip and gem
on the same system.
I do think that native packages are what Package should manage and
everything else should be its own type/provider combo because they are,
indeed, *something else*.
This gets hairy with RPM since Debian, etc... can all install and use the
RPM command so I'm not sure quite how to handle that one. I suppose that
native types could be created for everything but just call the appropriate
backend if not called explicitly. That does let people use package{} and
rpm{} on the same system though.
Trevor
On Thu, Mar 13, 2014 at 9:23 AM, John Bollinger
<[email protected]>wrote:
>
>
> On Thursday, March 13, 2014 8:02:22 AM UTC-5, Trevor Vaughan wrote:
>>
>> Looking at the list of providers for file, on RHEL systems you'll
>> probably only run into conflicts with *native* (yum, rpm, up2date), pip,
>> and gem.
>>
>> I also am not opposed to this. As far as I can tell, 'package' is the
>> only type that doesn't follow the rules of the other types (manage one
>> thing and manage it well). It rolls lots of different things under the same
>> abstract header.
>>
>>
>
> Exactly so. If there is a design flaw here, it is that the meaning of the
> Package type is fuzzy. It *should* represent software packages for the
> target node's native package management system.
>
>
>
>> Frankly, if I have to specify provider => 'gem', that's not any more work
>> than specifying gem { 'name': ... } and the latter is a lot clearer in
>> terms of dependency maintenance.
>>
>> So, +1 from me for just creating a bunch of new types.
>>
>>
>
> That would work for me. Alternatively, there could be just one new type,
> say SecondaryPackage, that rolled up gem, pip, fink, etc.. 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.
>
>
> 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/67e90ed8-a8af-4e3a-a02b-f8f2e2ee035a%40googlegroups.com<https://groups.google.com/d/msgid/puppet-dev/67e90ed8-a8af-4e3a-a02b-f8f2e2ee035a%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%2BFoWn-gYoTyx8s54_FEgoNEtm5kLSE3Y%2B7B-uRFgM7NP5FQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
