Backporting policy

[Lamar Owen]

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