Bug 102639 - Insufficient dependency information in kernel packages
Summary: Insufficient dependency information in kernel packages
Alias: None
Product: Red Hat Raw Hide
Classification: Retired
Component: kernel   
(Show other bugs)
Version: 1.0
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Arjan van de Ven
QA Contact: Brian Brock
Depends On:
TreeView+ depends on / blocked
Reported: 2003-08-19 09:14 UTC by Panu Matilainen
Modified: 2007-04-18 16:56 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2003-08-19 11:54:42 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Panu Matilainen 2003-08-19 09:14:33 UTC
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

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:

Steps to Reproduce:
1. See http://distro2.conectiva.com.br/pipermail/apt-rpm/2003-August/001946.html

Comment 1 Jos Vos 2003-08-19 10:14:24 UTC
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

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.

Comment 2 Panu Matilainen 2003-08-19 10:23:06 UTC
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

Comment 3 Jos Vos 2003-08-19 10:36:10 UTC
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.

Comment 4 Arjan van de Ven 2003-08-19 11:54:42 UTC
*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.

Comment 5 Panu Matilainen 2003-08-19 12:11:08 UTC
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.

Comment 6 Arjan van de Ven 2003-08-19 12:15:55 UTC
no that is not all that is needed since you STILL don't have the full dependency

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.

Comment 7 Panu Matilainen 2003-08-19 12:30:19 UTC
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. 

Comment 8 Jos Vos 2003-08-19 12:36:12 UTC
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.

Comment 9 Arjan van de Ven 2003-08-19 12:39:40 UTC
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.

Comment 10 Jos Vos 2003-08-19 12:46:54 UTC
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.

Comment 11 Panu Matilainen 2003-08-19 13:00:49 UTC
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.

Comment 12 Axel Thimm 2003-08-19 18:06:07 UTC
I second Panu's view. For healthy kernel module dependencies something like

Provides: strictdep-kernel[-<flavour>]-%{_target_cpu} =

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

Note You need to log in before you can comment on or make changes to this bug.