> On Thu, Mar 13, 2014 at 9:23 AM, John Bollinger
> <[email protected] <mailto:[email protected]>> wrote:
> > That would work for me. Alternatively, there could be just one new
> > type, say SecondaryPackage, that rolled up gem, pip, fink, etc.
On 03/13/2014 02:50 PM, Trevor Vaughan wrote:
> SecondaryPackage wouldn't fix it if you wanted to install using pip and
> gem on the same system.
Huge +1. John, would you have us dance this one again in a year or two? ;-)
> This gets hairy with RPM since Debian, etc... can
> all install and use the RPM command so I'm not sure quite how to handle
> that one.
Ugh, that is a much better point than I'd like to admit.
It could be handled by the "pick subtype based on provider value" rule I
sketched earlier, if we opt to *not* let dpkg, rpm and friends remain
un-subtyped.
It's not even that much of an outer edge case, because given a Debian
box on which you want/have to use this RPM from Corporate IT, this would
be a likely manifest:
package {
"puppet": provider => "dpkg", ensure => absent;
"puppet": provider => "rpm", ensure => present;
}
And yes, specifying that the rpm should require the dpkg would be hella
non-intuitive (require Package["puppet:dpkg"]? Dpkg_package["puppet"]?
Code readability anyone?) In that vein, it would indeed be helpful to
allow the alternative syntax of
dpkg_package { "puppet": } vs. rpm_package { "puppet": }
...but that will introduce new pitfalls for users, I believe. Full
vicious circle.
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/5321BD0F.5090507%40alumni.tu-berlin.de.
For more options, visit https://groups.google.com/d/optout.
