funny way of numbering kernel versions
davej at redhat.com
Wed Nov 17 17:13:05 UTC 2004
On Tue, Nov 16, 2004 at 11:33:25PM -0800, Per Bjornsson wrote:
> On Wed, 2004-11-17 at 02:11 -0500, Dave Jones wrote:
> > > 2.6.9-1.650_FC4 will not be higher than 2.6.9-1.667
> > Damn, you got me. This is the only annoying thing with having
> > multiple releases on the same kernel level. They're not
> > /exactly/ the same kernel, and as they come different
> > parts of the CVS tree, it's perfectly feasable for
> > a 2.6.9-1.650 to show up in FC2, FC3, and devel (FC4).
> I sure hope not, you just can't put out an update for a released distro
> that doesn't get scored as higher by RPM... Presumably I'm misparsing
> what you're saying here?
yes, you are. updates for a specific release will never go
backwards, but if I get a bug filed against 2.6.9-1.650,
I don't know if that's the FC2 version, FC3, devel...
> > I could do something really ugly, and just bump the
> > devel kernels up past the last released FC3 kernel
> > each time I do an update, but that is a little sick.
> Well, here's a suggestion that you might want to shoot down as stupid
> and uninformed: How about using the first digit of the release tag? What
> does it actually mean for the kernel - for other packages it's certainly
> just a serial number... Why not bump it to "4" right away, and then let
> that digit spill over to the stable FC4 kernels when Rawhide takes off
> on the "5" path. Alternatively, of course, there's some deep meaning to
> the number "1" which prevents this from being sane at all.
You mean use 2.6.9-4.650 ? unfortunatly the '1.650' is the CVS tag.
without some creative forking, its not going to work.
More information about the test