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
<john.bollin...@stjude.org>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 puppet-dev+unsubscr...@googlegroups.com.
> 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
tvaug...@onyxpoint.com
-- 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 puppet-dev+unsubscr...@googlegroups.com.
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.
