On Tuesday, March 11, 2014 4:23:33 PM UTC-5, Pedro Côrte-Real wrote:
>
> On Tue, Mar 11, 2014 at 5:29 PM, Andy Parker
> <[email protected]<javascript:>>
> wrote:
> > Personally, I would be ok with yet another hack in puppet 3 to handle
> this
> > issue since it has been coming up so often and since I also don't know a
> > clear timeline for getting new functionality in to address this specific
> > issue in a better way. And yes, my idealism is cracking :/
>
> It's great to finally see traction on this. I still don't understand
> why this is a hack though. This is what is broken:
>
> package {"foo_deb":
> name => foo,
> provider => apt,
> }
> package {"foo_gem":
> name => foo,
> provider => gem,
> }
>
> But the only reason this doesn't work is that we used $name to
> override the deb/gem name. This on the other hand would work fine:
>
> exec {"foo_as_root":
> command => "/bin/foo",
> user => root,
> }
> exec {"foo_as_someuser":
> command => "/bin/foo",
> user => someuser,
> }
>
> Yet the only difference between the two cases is that we used $command
> and not $name to override the default given by $title.
>
>
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.
> Package was designed assuming the meaningless tokens we pass to apt to
> select debs have some relation to the meaningless tokens we pass to
> gem to select gems.
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.
This is just a bug in Package, fixing it isn't a hack.
>
>
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'?
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/af52b6dc-f463-41fa-a355-770bf8804522%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
