Sorry for the double post but I just thought of this.
1) The ldap provider probably needs to be removed from 'user'. Yes, they
are users but they're not native, they could be one of many things.
2) If we do want to keep gem as a package provider, you'll need something
like the following:
service { 'my_service': require => Package['mysql']{ :provider => 'gem' } }
This way, you end up with the correct resource relationship instead of
being bound to the mysql RPM and the mysql Gem (or worse, neither because
Puppet can't figure it out).
I am not a fan of this as I think it decreases readability. I would much
rather have:
service { 'my_service': require => Package_Gem['mysql'] }
I made this package_gem just to keep things alphabetical for human code
parsing.
I definitely understand the impulse behind wrapping all items behind a
simple front but I think that it decreases readability and makes
maintenance more difficult.
For instance, things that I can think of off the top of my head:
Types of Packages:
http://en.wikipedia.org/wiki/List_of_software_package_management_systems
Types of Users: <the usual>, htaccess, htdigest, tomcat, ldap(posix),
ldap(other), weblogic, mysql, postgres, dovecot, postfix, (pretty much you
name it....)
Personally, I don't want all of these smashed into the same high level
interface.
Trevor
On Wed, Oct 8, 2014 at 6:49 AM, Trevor Vaughan <tvaug...@onyxpoint.com>
wrote:
> 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 <
> daniele.sluijt...@gmail.com> 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 <john.bo...@stjude.org>
>>> 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 <john.bo...@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?
>>>>>
>>>>
>>>>
>>>> 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+...@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
>>>> <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
>>> tvau...@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/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
> tvaug...@onyxpoint.com
>
> -- This account not approved for unencrypted proprietary information --
>
--
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%2BFoUB8KD8U8-2%3DpjH7VtmJ%2BeF_7dSjdGBGYVobAoo0MKQeg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
