On Sat, Oct 2, 2010 at 3:02 PM, Michael Stahnke <[email protected]> wrote: > I'm not sure it's upstream hurting users. EPEL won't move the > version of cfengine or puppet (although we have moved puppet in the > past) for the EL4/5 systems. Thus the choice is either get the latest > from epel and rebuild the latest on the older systems, or the opposite > try and build the old package on the newer EL version. Either way, > it's a dis-service to everybody involved because the packages are not > in step with each other across distros. This often leads to people > complaining about EPEL and then rolling their own packages or tarball > or gem installations into their environment. > > The reason EPEL normally doesn't move these packages is that they > often times do introduce API/ABI breakage, so I'm not sure what the > best answer is, but I know I would still want all of my servers to be > managed through the same policies and at the same client version so I > have the same features available to everything inside my > infrastructure. > > stahnma >
In the case of cfengine, v2 vs. v3: v2 is no longer supported at all from upstream. However, I'm pretty sure that v2 clients will work fine with a v3 server (someone please correct me if I'm wrong). Because v2 is no longer supported upstream I'm hard pressed to find a reason to support it in EPEL6 onwards. A very unscientific survey (me talking to some random subset of cfengine users) has led me to believe that many in the community are assessing their options before making the move the v3 and are still using v2 in the meantime. In this case upstream has not left people with many choices: it's either move to v3, continue with v2 without any support or security fixes, or move to another configuration management system. If upstream were to continue to support v2, I would gladly build v2 and v3 versions for all supported EPEL releases, but this is purely hypothetical as it has already been decided upstream to drop v2 completely. -Jeff _______________________________________________ epel-devel-list mailing list [email protected] https://www.redhat.com/mailman/listinfo/epel-devel-list
