Backporting policy

[Christian Pearce]

I guess this is the challenge.  Sometimes moving forward will suck or be easy.  And sometimes backporting with suck or be easy.  And in some case they both are easy or suck at the same time.

Fun.

I am reminded of the Far side cartoon.  The sign reads on one door, "Damned if you do." The sign reads on the other door, "Damned if you don't."  There are people in line in hell and the devil says, "Come on it is either one or the other."

Let's strive for a policy of backporting.  If we find ourselves in a position that it is easier to move forward so be it.  If we find ourselves in hell, then the first person to solve the problem wins.

--
Christian Pearce
http://www.commnav.com



Lamar Owen said:
> 
> 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
> 
> 
> --
> fedora-legacy-list mailing list
> fedora-legacy-list at redhat.com
> http://www.redhat.com/mailman/listinfo/fedora-legacy-list
>