On 01/-10/-28163 02:59 PM, Always Learning wrote: > > On Thu, 2011-09-08 at 20:00 -0400, Ross Walker wrote: >> On Sep 7, 2011, at 9:57 AM, Always Learning<centos at u61.u22.net> wrote: >> >>> Perhaps a silly question, but why maintain patches ? Why not compile a >>> new version and discard all the patches ? Patches are a messy manner to >>> maintain programmes. > >> RHEL needs to keep the same ABI (application binary interface) for both >> kernel and user programs so third party VARs and software developer's >> binary packages will continue to be compatible during the lifetime of >> a release (5.X or 6.X). > > According to my brief 30 seconds understanding of ABIs from Wikipedia, > that does not seem relevant to patching. The ABI is just a calling > convention. The parameters used and the data exchanged is predetermined > otherwise nothing would work. Parameters and data formats remains > constant throughout the life-time of the software. That has always been > the way for all inter-programme communications. > >> In order to do that RH keeps (or makes all attempts to) the same >> versions of the software during the release while back porting >> security updates and must-have features that don't change these ABIs. > > Anything which is patched is, by definition, not the same version as the > original version although the version number can remain the same and the > functionality generally remains the same. Obviously the ABI should > remain the same otherwise other programmes would be unable to > successfully exchange 'data'. > >> These back ported updates are the patches that are applied to the base >> package. > > Which means some systems, patched locally, may have to then re-apply > their patches to the base system ? > >> That should make it crystal clear. > > Regrettably it did not. Another poster, whose name I can't recall at > this moment, explained the patched practise as being able to restrict > charges to specific modules while maintaining unaltered core > functionality and having the flexibility to customise a base package for > specific requirements. Generally the reason that packages on RHEl have patches back-ported instead of simply updated to the latest version is because of the version dependencies other packages may have. The entire RHEL distribution, as are most others, is pervasively permeated by intricate package inter-dependencies. Changing the version number of one may well start a cascade of failed dependencies in other, apparently unrelated packages. Also, the idea of backward API compatibility is not given much consideration in many FOSS projects in my experience. Injecting a new version of some software into the distribution may well disable parts of it that depend upon a now deprecated function. It is well to remember that the reason new versions of RHEL take so long to appear is the effort that goes into making sure that every package contained therein will build and inter-operate correctly with all of the others. No-one concerned with getting it to work in the first place really wants to introduce potentially substantial changes. -- *** E-Mail is NOT a SECURE channel *** James B. Byrne mailto:ByrneJB at Harte-Lyne.ca Harte & Lyne Limited http://www.harte-lyne.ca 9 Brockley Drive vox: +1 905 561 1241 Hamilton, Ontario fax: +1 905 561 0757 Canada L8E 3C3