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 <
felix.fr...@alumni.tu-berlin.de> 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 puppet-dev+unsubscr...@googlegroups.com.
> 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
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%2BFoWj%3DsJN_xUY9Rntqid6K7%3DXK-5sJrsbmbJzZ78Rgak%3D%2BA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
