Whether such an alternative type is called Secondary_package or
Module or Software, or whether there are several (Gem, Pip, Cpan,
...) is very much a secondary concern to me.
John
Perfect. I understand what you're saying and I agree.
--
You received this message because you are
I greatly favor anything else over making Package non-isomorphic.
I completely appreciate what you're saying. However, I don't think this was
the intent of the provider abstraction. It was intended to make the
OS-specific provider transparent, right? The different types of packages
we're
This is the best idea I've heard. Certain puppet types intend to provide an
abstraction. This abstraction only works for native package providers in
this case because anything else requires the user to make an informed
decision. I think having all other package providers be separate types is
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
I am pretty sure a composite namevar won't be necessary. It will just be a new
param such as pkgname that, if not specified, would default to the resource
title/name for backward compatibility.
Since we have the go ahead from Puppet, does anyone have the know-how to do
this? I could try to
individual cases work as expected.
On Mon, Mar 10, 2014 at 6:09 AM, Drew Blessing
drew.b...@buckle.comjavascript:
wrote:
I agree, it seems like this solution would be simple and effective. I am
almost positive there are other types that behave this way. It breaks
nothing and fixes
, but I'd like this fix in Puppet 3 and
the RAL update in Puppet 4/5/whatever.
Trevor
On Mon, Mar 10, 2014 at 11:15 AM, Drew Blessing
drew.b...@buckle.comjavascript:
wrote:
Unless you can definitively say that making major changes in the RAL to
address this issue is slated for the near
I want to start a conversation about the package resource type and a bug
that goes back about 6 years. The current ticket
is https://tickets.puppetlabs.com/browse/PUP-1073 and relates to really old
tickets such as https://projects.puppetlabs.com/issues/973.
If I have gem 'x' and RPM 'x', I
I've been following this discussion for some time. As it progressive I've
found myself fighting internally, going one way and then the other about
how this should really be. I keep coming back to the same place - this is
a bug and Luke's original statement is very important:
The fix should
