> On Thu, Mar 13, 2014 at 9:23 AM, John Bollinger
> <john.bollin...@stjude.org <mailto:john.bollin...@stjude.org>> 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 puppet-dev+unsubscr...@googlegroups.com.
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.
