Hide Forgot
Description of problem: It's currently impossible to have dependency on exact version-release on the uniprocessor kernel due to quirk/feature in the way rpm handles versioned dependencies: All the kernel rpm's have "Provides: kernel = %{version}" which makes rpm think it covers all releases of that version, for example if I have a package which has "Requires: kernel = 2.4.20-19.9" rpm still considers the dependency satisfied if I only have eg. kernel-2.4.20-8 installed. See the thread at http://distro2.conectiva.com.br/pipermail/apt-rpm/2003-August/001946.html for more details if necessary. Could you please refine the dependencies a bit to make it possible to have exact version-release dependency on the "kernel" package (-smp and -bigmem don't have this problem because the package name is different from the provides)? I think the easiest and simplest way to achieve this would be adding "Provides: kernel-up = %{version}-%{release}" to the uniprocessor kernel package, packages can then have dependency on kernel-(up|smp|bigmem) = <version>-<release> Version-Release number of selected component (if applicable): Any current kernel How reproducible: Always Steps to Reproduce: 1. See http://distro2.conectiva.com.br/pipermail/apt-rpm/2003-August/001946.html
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.