Backporting policy
Lamar Owen
lowen at pari.edu
Thu Jan 8 16:23:14 UTC 2004
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
More information about the fedora-legacy-list
mailing list