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