On Sep 8, 2011, at 9:16 PM, Always Learning <centos at u61.u22.net> 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. Ok, let's say version X of a given software package has a security flaw in it. This security flaw has been fixed in version Y of the same package, but version Y has a slightly different functionality, maybe it is in some shared libs or maybe just in how it presents itself in procfs/configfs. Now RH needs to fix this security flaw in the existing version X of the package, this package's existing interface needs to remain constant because software vendors have products out there that depend on it, so they reverse engineer or diff out the changes made to fix the security flaw without making any of the functionality changes. This then becomes a patch to the existing version X. It is applied as a patch in the SRPM because it's easy to incorporate, track, document and back-out if necessary. Over time the software packages and the kernel itself will accumulate multiple patches. >> 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'. Yes, RH packages are NOT the same as the originals, they have security patches and maybe some performance fixes from the originals, but they keep the ABI the same, and thus keep the version numbers the same. There are version numbers appended to the upstream version to differentiate the packages and determine the fix level of a given package through it's lifetime. >> 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 ? No, these patches are incorporated into the SRPMs used to build the binary RPM packages and they become the distribution, after a certain amount are accumulated they re-target the distribution at a point release 5.1, 5.2, etc. >> 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. I'm sorry I wasn't very clear to begin with, maybe this helped? -Ross