On Thu, 2008-02-14 at 10:46 -0600, inode0 wrote: > On Thu, Feb 14, 2008 at 9:15 AM, Sharpe, Sam J > <[EMAIL PROTECTED]> wrote: > > > > On Thu, 2008-02-14 at 08:49 -0600, Daryl Herzmann wrote: > > > I was puzzled to see the most recent kernel errata come out with a > > version > > > number of "2.6.18-53.1.13" compared with the last kernel of "...6", > > that's > > > 7 bumps for fixing 1 security issue? > > > > That refers to the build of the RPM, not the version of the kernel. > > 2.6.18 is the Kernel version, 53.1.13 is the RPM version number. > > > > > > When I build an RPM, I change the version every time I make an update to > > the RPM, whether it fixes an issue or it fixes a fix to an issue. > > > > Lets say I apply a patch, so I bump the RPM version up. I then find out > > that the patched binary didn't work properly, so I redo it (new > > version). I then find out that fixing this broke some other thing, so I > > correct that and rebuild (new version number). I then find out I forgot > > to update the changelog in the .spec file, so I update that and rebuild > > (new version number). > > > > I can quite easily believe that including one patch requires multiple > > RPM rebuilds and therefore a huge number of version changes in the > > RPM... which explains why it's 2.6.18-53.1.13 rather than 2.6.18-11 (I'm > > making up the 11 versions, I think there's been loads more kernel RPM > > releases in RHEL4.) > > If you actually look at the changelog you will see exactly which fixes > went in at each level from .7 through .13 ... no gaps, no holes, no > oops I need to rebuild this rpm.
err, that's nice. However, if you actually *read* the changelog you might ask: "what happened between 2.6.18-10 and 2.6.18-12... Where is the changelog for 2.6.18-11?" or "I know what -10 fixed and I know what -12 fixed, but what did they slip into -11 that isn't listed?" The point I was making is that the 53.1.13 is an RPM version number, not related to how many issues were necessarily fixed in the kernel. I did that by imaging a number of build steps that might be required just to fix a single issue... You also provide the counter example - a single version bump contains multiple patches and therefore fixes multiple issues. -- Sam _______________________________________________ rhelv5-list mailing list [email protected] https://www.redhat.com/mailman/listinfo/rhelv5-list
