On Tue, 2008-10-14 at 14:31 -0600, Kevin Fenzi wrote:
On Tue, 14 Oct 2008 05:43:05 +0200 rc040203@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