Fixing Puppet in Fedora/EPEL

Todd Zullinger tmz at
Tue Oct 23 02:51:19 UTC 2012

Ken Dreyer wrote:
> On Fri, Oct 19, 2012 at 5:35 PM, Matthew Miller 
> <mattdm at> wrote:
>> I'm not opposed to putting puppet 3 in, but it'd really be helpful if it 
>> went in as "puppet3" or something, and left the stable version as is, 
>> happily getting security-only updates.
> My biggest concern is that 2.6 will not get security updates for the 
> lifetime of EPEL 5 and 6. To me it seems better to bite the bullet 
> now, get version 3 into updates-testing, set the karma requirement 
> very high just as the maintainers did for the 0.25 -> 2.6 transition.

I'm sure that 2.6 won't last for the life of EL5, let alone EL6.  At 
the same time, I didn't push to get 2.7 in EPEL because it isn't a 
completely compatible update.  And 3.0 was coming so I figured we 
could wait to see what things looked like when it did.  The 
alternative would have been more updates and more potential to break 
things and annoy the users who were perfectly happy with how 2.6 was 
working.  (Those that needed the newest shiny or were supporting 
Fedora 17 could get newer bits from

> This is the main problem I see with parallel-installable packages, 
> particularly in EPEL - it seems to give users an assumption that the 
> old packages are fine.

Yeah, that's always bugged me too.  If you're not paying close 
attention, you can easily assume that since yum update returns nothing 
that you are good to go.  In that case, I'd much prefer that an update 
comes along and gets your attention, even if it breaks things.  
Obviously, neither option is all that great.

As a user, I think compatibility is the biggest downside to puppet at 
this point.  I love the tool, but having to always run the master on 
the latest version bugs me.  At the least, I think a version N client 
should work fine with an N-1 master.  Back in the pre-1.0 days it was 
acceptable to not have this, but as the versions have been increased 
to show product maturity, I think it's hard to justify not maintaining 
more compatibility.

I'm happy to see options here and get a feel for what the least 
painful way forward is for everyone.

I'm not terribly fond of a puppet3 package myself.  It would be 
confusing to have it parallel installable and use different paths than 
the upstream defaults, as documenation would either be wrong or 
require a lot of conditional statements regarding where and how you 
installed puppet.  That and it's more work to maintain, regardless of 
who's maintaining it.

Thanks to Michael for bringing this topic up for discussion (and for 
being an all around good guy as well).

Todd        OpenPGP -> KeyID: 0xBEAF0CE3 | URL:
Abandon the search for Truth; settle for a good fantasy.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 543 bytes
Desc: not available
URL: <>

More information about the devel mailing list