I just realized that there's another way around this. It's not so glamorous
as fixing the type, but it would work.
Just create new types that inherit the package type and hard code the
provider.
package_yum
package_gem
etc....
This would probably be pretty quick work overall and, of course, eliminates
all of the conflict issues.
But....it doesn't feel like a good solution.
Trevor
On Wed, Mar 12, 2014 at 4:15 PM, Pedro Côrte-Real <pe...@pedrocr.net> wrote:
> On Wed, Mar 12, 2014 at 6:35 PM, John Bollinger
> <john.bollin...@stjude.org> wrote:
> > No, that's not really a difference at all. 'command' is the namevar of
> the
> > Exec type (it has no 'name' property), and 'name' is the namevar of
> Package.
> > It is the fact that 'name' is the namevar of Package that makes the
> package
> > version not work. That the Exec version does work is the result of a
> > special-case exception for that resource type; it has nothing in
> particular
> > to do with the name of the type's namevar.
>
> My question is why does $command or $pkgname (in my example) have to
> be a namevar? I assumed $command actually wasn't a namevar. I
> understand the problem now though (see below).
>
> > I think Package and most other built-in types were designed around the
> idea
> > that only one provider would ever be used on any given target system.
> And
> > indeed, that's a superior policy, at least when it comes to packages.
> That
> > it works -- up to a point -- for multiple package providers is a
> secondary
> > feature. Now I'm not saying that's an ignorable feature or one that
> > shouldn't be improved, but on the other hand I do not favor creating
> > additional special cases for particular resource types.
>
> That may very well be the historical reason. It's a totally arbitrary
> restriction though. Once you support multiple providers on the same
> system saying that "foo in gem conflicts with foo in apt" doesn't make
> much sense.
>
> > It is not a bug in Package, it is a natural consequence of Puppet's
> > architecture. Resource providers cannot (reliably) be distinguishing
> > characteristics of any resource type, because for the most part they are
> not
> > assigned or known during catalog compilation.
> >
> > Consider this:
> >
> > package { 'foo_native':
> > name => 'foo',
> > }
> >
> > package { 'foo_gem':
> > name => 'foo',
> > provider => 'gem',
> > }
> >
> > Do those declarations refer to the same resource or not? What if the
> target
> > machine is some screwball system for which the default package provider
> is
> > 'gem'?
>
> This makes more sense. I'd just assume the user knows what he's doing
> because he has to anyway. Asking for "Package[foo] from whatever
> package system the target has" is not a useful thing to do because
> there is no standardization of names between package systems. You
> already have to know what package system you are targeting to be able
> to select the package name. Enforcing the namevar constraint in this
> case just hurts the user.
>
> But if you want to keep it pure make this case conflict and only allow
> the case where both Package declarations have a provider declared, so
> you know the provider at compilation, it's less flexible but much less
> of an issue than the current solution.
>
> Cheers,
>
> Pedro
>
> --
> 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/CALprHx8bXHLiwWaUq3iSxqYw78OmmxA6FcDdF5O1C8jKo9fFRQ%40mail.gmail.com
> .
> 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%2BFoWRL4pB7f-yO8eeDKjztvRJ06ThifswDCjyfpP6JDbcSw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
