On Thu, Mar 08, 2007 at 05:21:53PM -0500, Bill Nottingham wrote:
Mike McGrath (mmcgrath(a)redhat.com) said:
> Fedora extras supports a lifecycle that is less than two years.
> Typically about 1 year. EPEL is different, requiring many years. If I
> release nagios 2.7 right now in EPEL (which I have), I'll still be
> maintaining it in 2010. At which point in time nagios might not even
> exist anymore, or it could be at version 5.3. The fact is there is NO
> way you're going to get me to do backports of it if a vulnerability is
> found. Its just not going to happen, mostly because I'm a terribly
> crappy programmer. Packagers != programmers. Backporting requires
> skilled labor which not everyone (including myself) will be able to do
> for antient packages (which nagios 2.7 will be by 2010).
An interesting side point is what some ISVs actually do. When RHEL 3
was released, Adboe made a version of Acrobat Reader that ran on RHEL 3,
and supported it with various updates for security.
However, as time has passed, they have officially EOLed the version that
ran on RHEL 3, as their only current version (with security fixes, etc.)
requires an entirely new GTK/Pango/etc stack.
I suspect there will be plenty of stuff in EPEL that will eventually
be frozen to the point where it may only get a backported security
fix or two, simply because newer things just *will not build or run*
on that version of RHEL/CentOS.
The question is how do we deal with it? Will we have enough resources
to throw to backporting? Probably not, especially when there was a
company once pushing a set of packages and suddenly drop them and
moves on to the next RHEL version.
What will we do in 12 months with say 40 packages in RHEL4 and 20 in
RHEL5 with security issues requiring backporting labour that noone is
willing to donate? Removing them from the repo will still leave many
RHEL boxes vulnerable. Maybe the meta-package obsoleting/conflicting
with some packages which Thorsten suggested in Fedora-land in a
different context makes much more sense here?
Axel.Thimm at ATrpms.net