Looking at the list of providers for file, on RHEL systems you'll probably
only run into conflicts with *native* (yum, rpm, up2date), pip, and gem.
I also am not opposed to this. As far as I can tell, 'package' is the only
type that doesn't follow the rules of the other types (manage one thing and
manage it well). It rolls lots of different things under the same abstract
header.
Frankly, if I have to specify provider => 'gem', that's not any more work
than specifying gem { 'name': ... } and the latter is a lot clearer in
terms of dependency maintenance.
So, +1 from me for just creating a bunch of new types.
Trevor
On Thu, Mar 13, 2014 at 8:24 AM, Drew Blessing <drew.bless...@buckle.com>wrote:
> I am kind of interested in what you describe. I think for our environment,
> keeping the package type as is and creating a new ³gem² type that inherits
> from package would be just fine. If we only consider RHEL-based systems
> for a moment, is there really a possible conflict scenario other than
> yum/rpm and gems (where you wouldn¹t be insane for trying to install
> multiple packages of the same name)?
>
> It would still be nice to see some work go into the RAL for Puppet 4 and
> have a permanent solution. However, would it be easier in Puppet3 if
> someone just created a ³gem² module that had the inherited type/provider
> in it? It would be trivial to do that.
>
> Drew
>
>
> On 3/13/14, 6: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 a topic in the
> >Google Groups "Puppet Developers" group.
> >To unsubscribe from this topic, visit
> >https://groups.google.com/d/topic/puppet-dev/LatVZFUkwEM/unsubscribe.
> >To unsubscribe from this group and all its topics, 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.
>
> --
> 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/CF470C6D.14D64%25drew.blessing%40buckle.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%2BFoVh%3Dv%3DHqZLCu2CVd2eD%2Bq9Ok%2BKAH%3DJa7JyQAFfkOr26YQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
