funny way of numbering kernel versions

[shrek-m at gmx.de]

> > >  > 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.
>

$ rpm -qa kernel*

kernel-2.6.9-1.667
kernel-doc-2.6.9-1.667
kernel-utils-2.4-13.1.39

give the kernel the release-name ?

eg.
kernel-fc2-2.6.9-1.667
kernel-fc3-2.6.9-1.667
kernel-fc4-devel-2.6.9-1.667

-- 
shrek-m