Fixing Puppet in Fedora/EPEL
tmz at pobox.com
Tue Oct 23 02:51:19 UTC 2012
Ken Dreyer wrote:
> On Fri, Oct 19, 2012 at 5:35 PM, Matthew Miller
> <mattdm at fedoraproject.org> 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 yum.puppetlabs.com.)
> 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
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: www.pobox.com/~tmz/pgp
Abandon the search for Truth; settle for a good fantasy.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 543 bytes
Desc: not available
More information about the devel