On Tue, 2008-10-14 at 14:31 -0600, Kevin Fenzi wrote:
On Tue, 14 Oct 2008 05:43:05 +0200
rc040203(a)freenet.de (Ralf Corsepius) wrote:
> On Mon, 2008-10-13 at 10:16 -0500, Jeffrey Ollie wrote:
...snip...
> >
> > Unfortunately, upstream developers don't always release bugfix-only
> > releases. Many times they introduce new features or change the
> > behavior of old features.
> Right, and how do you expect EPEL to handle this issue?
>
> I would expect EPEL to starve out contributors during RHEL's long time
> time and those who will try to continue supporting it, will be facing
> the problems you described.
>
> May-be I missed it, but I would like to hear about EPEL's visions on
> this matter.
Sorry for the late reply.
In many ways EPEL has it easy. Since they don't maintain the kernel,
glibc, and all the other packages that RHEL maintains.
But you are right, for the packages they do maintain it will get harder
over time to backport security fixes or avoid updating versions.
I think the fact that EPEL doesn't have to handle those more
vulnerable core packages, and only has to worry about the leaf node
packages is one thing that makes it more viable.
OK.
Also, note that since many of the packages in EPEL are leaf nodes /
add on packages they don't tend to have deep dependencies that more
central packages have.
OK, so you're basically ignoring this issue and hope for the best?
Certainly, the likelihood of such an incident to happen in "non-core
packages" is less than in "core packages" and the severity of such
incidents in "leaf-packages" is likely less than that in core packages,
nevertheless they are possible to happen over the long time span EPEL is
supposed to be around, nevertheless are non-core packages which can have
long and deep dependency chains.
I only need to have a look into the packages I maintain in fedora ;)
Ralf