On 29.04.2007 21:08, Dave Jones wrote:
On Sun, Apr 29, 2007 at 03:03:42PM +0200, Thorsten Leemhuis wrote:
> So, what will we do in the future? Can we (after F7 is out and rawhide
> rolls again) please switch to something less confusing where version
> somehow allows normal users to clearly see what kernel they got? And one
> that doesn't confuse outside modules? Something like
How does this help up until rc1 ?
That's a good question I don't have a answer to myself, as Linus seems
to increase "SUBLEVEL =" in Makefile when releasing rc1 afaics. So for
this case I'm fine with either going with
As the number before ".fc7." increases in any case we don't have to care
what comes after in in %release as it won't confuse rpmvercmp.
For example right now, upstream is 2.6.21-git2, yet there's
14MB of patches already, (and much more to come before .22rc1)
so it's clearly not .21 and is likely to break anything
that relies upon kernel interfaces not changing vs .21
and it's not .22 either yet.
I just want no special Fedora handling. Just let the Fedora kernel
identify itself similar to what upstream would do, as everything else
just confuses external modules and users -- the latter includes probably
other Kernel developers as well, if they are not aware how Fedora
versions its kernels. If seen that on LKML once or twice.
the package versioning isn't whats relevant here, it's the
versioning in version.h that broken external drivers
insist on comparing against instead of comparing against
#defines to check for features.
Yeah, but that how life is ^w^w external module authors are.
Finally, there are cases where we'll change a prototype
of a function in Fedora vs upstream when we backport
something early, or develop some new feature etc, so
just matching the version number isn't a panacea anyway.
Happens, we are all used to it. But that is not relevant for the
discusson at hand IMHO, as that "feature" is independent of version and
release in any case (e.g. it can happen to you in final or rc kernels).