On Mon, 2009-03-30 at 18:45 -0500, Michael Stahnke wrote:
We have pulled EPEL directly in some cases, but still, we don't
updates without really looking into them. I think that's more what I
was trying to ask.
Understand. Although I still highly recommend Enterprises or even SMB
operations consider their own, internal, Custom Repos (YUM) or Custom
Channels (Spacewalk/RHN Sat) for release control.
I hope people aren't just running yum-cron or 'yum
-y update' in cron on EL. I mean, from a maintainers perspective,
having to have Nagios3 and Nagios isn't fun. From a client
perspective, you'd probably like both. You'd HATE it if you went from
2->3 and it broke all your monitoring, because you might not catch
that for a while...
I'm a tad ignorant on the standards for EPEL beyond the basics. But I
would assume a major version change that requires reconfiguration would
be implemented with a suffix on the package name (e.g., nagios3-3*),
much like RHEL, instead of a major version change with the same package
name (e.g., nagios-2*).
I know EPEL is not RHEL with the manhours to support backports. But as
long as Nagios 2.x is supported upstream, I would segment the two. When
Nagios 2.x development is suspended upstream, then that would be the
ideal time to consider rebasing the main package with no version suffix.
I'm hardly an authority on EPEL and produce little more than hotair from
a package standpoint, but that makes the most sense to me.
Bryan J Smith Senior Consultant Red Hat GPS SE US
mailto:email@example.com +1 (407) 489-7013 (Mobile)
mailto:firstname.lastname@example.org (non-RH/ext to Blackberry)
You already know Red Hat as the entity dedicated to 100%
no-IP-strings-attached, community software development.
But do you know where CIOs rate Red Hat versus other
software and services firms for their own, direct needs?
It's no comparison: http://www.redhat.com/promo/vendor/