I think I just realized what I actually want to be able to do when creating
types in a generic sense.
newparam(:name) do
isnamevar
...
end
newparam(:provider) do
isnamevar
...
end
Now, in the catalog, what would happen is that *all* parameters that were
named as namevars would be combined.
:title = "#{@resource[:name]}:#{@resource[:provider]}" (obviously looping
over all parameters and pulling out all that are namevars and clumping them
together in some rational order, possibly just alphabetical)
This is fundamentally what I would like to see in the end solution to the
more generic problem. And I still think that this type of thing should be
done since, whenever you use a composite namevar, you probably want this
instead.
The only sticking point here is on relationship dependencies. How do you
specify them?
* Package['name'] (that would pick up *all* of them or possibly just the
system default. Anything other than the system default would need to be
explicitly specified with one of the methods below.
* Package['name:provider'] (that would pick up the right one but relies on
knowing the implementation)
* Package['name(provider => "yum")'] (better since it's more specific and
not magic order dependent but still relies on knowing the implementation to
a point)
Trevor
On Thu, Mar 13, 2014 at 7:37 AM, Felix Frank <
[email protected]> wrote:
> On 03/12/2014 11:23 PM, Trevor Vaughan wrote:
> >
> > 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.
>
> I agree that the implementation you sketched is messy, but the basic
> idea has actually occured to me as well when I read John's latest reply.
>
> The assumption that the regular old system will only ever use one
> provider for a given type holds true for many use cases. Package is a
> notable exception insofar as it can now be used to manage things that
> are not OS packages (but also gems and what have you).
>
> IMO the source of the issues here is that a gem is fundamentally a
> different kind of package than the rpm/deb/... your OS uses for native
> software. (So are CPAN modules, puppet modules etcpp.)
>
> Creating new types that explicitly name the type of package they deal
> with would handle this, yes (although I would vote that yum/apt/dpkg/rpm
> and friends stay in the pure "package" domain if we should ever go that
> route).
>
> It would be nice if we had a system were the compiler could infer the
> subtype from the value of the provider parameter. Because really, we are
> only prone to hit conflicts when non-OS packages are requested via
> providers like gem/cpan/pecl/pear/forge/whatever.
>
> The generic enhancement of the Model would allow to auto-switch to
> subtypes via arbitrary rules, where going by the provider value would
> likely suffice for the package type.
>
> Regards,
> Felix
>
> --
> 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/53219896.6080206%40alumni.tu-berlin.de
> .
> 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%2BFoWj%3DsJN_xUY9Rntqid6K7%3DXK-5sJrsbmbJzZ78Rgak%3D%2BA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
