There is the kernel package issue and the rpm issue.

For the kernel package issue: I think the goal is to enable a package to rely on
a specific kernel version (including the release), so I'd suggest that all
kernel packages provide "kernel = %{version}-%{release}".  The UP kernel package
does that by default, the others have to be told explicitly.  Now all kernels
explicitly provide "kernel = %{version}", which triggers the rpm
problem/feature.

Now the rpm issue.  It appears that a provides of "%name = %version" satisfies
the requirements for *all releases* of that version. Although I vaguely remember
a discussion about this on the rpm list long ago, I can't see a reason for this.
Together with the kernel-rpm bahaviour, it currently makes it impossible to let
a package depend on a specific version-release combination of the kernel.

Note that if all kernels have "Provides: kernel = %{version}-%{release}" then
there's no way to have a dependency on the up-kernel, which is what we're trying
to accomplish here. Having all kernel packages provide the full version-release
info would be nice also but the provide-name has to be something else than
"kernel" as long as the up-kernel is named "kernel" (and not kernel-up) for
example. Renaming the uniprocessor kernel "kernel-up" might not be a bad idea
either.

True and I specifically agree with the last statement, so that kernel only will
be a virtual package.  Note also that a specific dependency on the UP kernel is
now impossible too, as *all* kernels satisfy any "kernel = version-*" now.

*ANY* package that has a dependency on an exact kernel is broken; you cannot
have such dependencies correctly.....
It's not just UP vs SMP, but also i586 vs athlon vs i686 and also having a
kernel installed is absolutely no guarantee that the functionality the Requires:
represents is available at runtime.

Arjan: the reason I'm asking for this is to allow 3rd party kernel-module
packages  have exact dependency on the kernel it was meant for. It's of course
up to the packager to make any i386,i586 etc variants available as well so than
a real match is possible. At least Fedora and Freshrpms have packages containing
kernel modules and currently there's no way to express the necessary dependency.
RHLP is supposed to support external repositories as well, right? Please
reconsider - the single "Provides: kernel-up = %{version}-%{release}" in up
kernel is all that's needed.

no that is not all that is needed since you STILL don't have the full dependency
information......

Also it puts strict ordering on the installation of kernel vs submodule (and
more importantly, upgrades of kernels)... your package doesn't need the
Requires:.. the modules will just go into a dir and get picked up by the kernel
when booted; that's not strictly a Requires: situation since your package
doesn't use anything from the main kernel package. (Ok, at runtime you link into
it but that's a runtime thing and not a strict requires)

In addition kernel-up is misleading since while on x86 the "kernel" package is
UP, on most other architectures it's actually SMP.

My definition of requires is slightly different then: kernel-module packages do
require a matching kernel to do anything useful :)

But ok.. handling upgrades (with apt/yum etc) with external kernel modules
requires some added logic anyway, can handle the thing as is, the provides
would've been just nice extra protection against user installing
kernel-module-foo rpm without any warnings and then wondering why it doesn't
work at all on his smp box. 

FWIW, this was all raised by the fact that with APT and Yum you now can't pull a
kernel package in by just adding "Requires: kernel = 2.4.20-18.9", as this
dependency is satisfied by all 2.4.20 kernels.  IMHO this is a strange behaviour
of rpm too (satisfying also explicitly specified releases), I do not understand
what is the rationale behind this.

the rationale is that glibc can now say
Requires: kernel > 2.2.5
or similar.
Any exact requires: on the kernel are broken imo since while you can guarantee
the kernel being installed, you cannot guarantee the kernel running; this is
unique to the kernel; for all other packages you DO get this garantuee... but it
makes for the fact that Requires: on a kernel are a bad thing in general.

No, that example does not explain why providing a version *only* by a package
(in this case the kernel), *without* a release, satisfies *all* releases of that
version when an explicit release is required (by some other package).

Maybe we should discuss this further on the rhl-devel-list, as this relates to
rpm behaviour and kernel packaging.  IMHO, if rpm would behave differently and
all provides lines in the kernel spec file would look like "kernel =
"%{version}-%{release}", both you and we should be happy, but maybe I'm missing
some point here.

rhl-devel is a better forum for further discussion, the issue of kernel modules
isn't exactly trivial like Arjan says: if the user installs, say, alsa-driver
now, does (s)he want it for the running kernel or for the latest installed
kernel which might be different (and remain so for long time) -> the decision
(policy) must be made somewhere else than rpm level etc.

I second Panu's view. For healthy kernel module dependencies something like

Provides: strictdep-kernel[-<flavour>]-%{_target_cpu} =
%{?epoch:%{epoch}:}%{version}-%{release}

could be introduced, which would be used by kernel modules to match exactly
NEVRA of the kernel compiled for.