On Thursday 08 January 2004 10:37 am, Charles R. Anderson wrote: > I think it is a myth that all Red Hat updates are backports. Ethereal > has always been upgraded rather than backported: It was and is on a case-by-case basis, with the Red Hat maintainers calling the shots for their individual packages. Red Hat did massive backporting fixes for PostgreSQL, for instance, where one cannot just upgrade to the next upstream version (and it is an example of what upstream developers think about backporting patches). If a major security flaw occured in the version of PostgreSQL that shipped with Red Hat 7.3, the likelihood of getting the upstream developers to patch that version is slim to none, and Slim just left town. Backporting the fix would not be trivial and might even require the resources of a PostgreSQL Core developer (which Red Hat has in the person of Tom Lane). That update (which at the time went all the way back to RHL 6.2, which has PostgreSQL 6.5.x, which is absolutely archaic by PostgreSQL standards (we're at 7.4.1 now!)) took _months_ for Red Hat to get out. XFree86, the Kernel, and a few other packages are in the same boat where someone with the real know-how to backport fixes will be required. Or press the RHEL 2.1 update source RPMs into service (which might work OK for RHL 7.2 and 7.3 for non-kernel patches). This is why Red Hat EOL'd these older distributions: they require massive resources to backport fixes where the upstream developers have no interest. Do we really understand the implications of things like the recent kernel vulnerability? The fix is in 2.4.24, but upgrading to kernel 2.4.24 might be out of the question for RHL 7.3, for instance, due to other dependencies. But then you run in to other issues. Let's take PostgreSQL as an example again. Suppose the only way to fix the issue is by forcing a major version upgrade. That's a massive undertaking for the user anyway, depending upon the version delta, but let's ignore that for a moment. The PostgreSQL developers are not static in their use of versions of things like autoconf, lex, and bison: they do update the build requirements periodically. A major PostgreSQL update may not even compile on the targeted EOL distribution. So it might pull in massive amounts of updates for the building tools. One can easily get into circular dependencies that basically require a complete dist upgrade. Right now, I am having a pretty sizable headache keeping the latest and greatest PostgreSQL working on older stuff. We go back as far as Red Hat 6.2 at the moment, but that could change at any time. -- Lamar Owen Director of Information Technology Pisgah Astronomical Research Institute 1 PARI Drive Rosman, NC 28772 (828)862-5554 www.pari.edu
