On Tue, Aug 19, 2003 at 01:23:11PM -0400, Jeff Johnson wrote:
On Tue, Aug 19, 2003 at 07:04:21PM +0200, Jos Vos wrote:
> Every package provides itself implicitly, as if the line
> "Provides: foo = 5.0-2" was in the spec file. This means that any
> dependency on "foo", "foo = 5.0", or "foo = 5.0-2" is
satisfied
> (as well as relational dependencies, like "foo >= 5.0" etc.).
> This is all the basic RPM dependency behaviour and pretty
> straightforward.
> [...]
> It also is the case that every kernel package provides
> "kernel = %{version}" explicitly. AFAIK this is mainly done to let
> kernel-smp, kernel-bigmem, etc. all "provide" the basic kernel too
> (but Arjan can tell much more about this, see also our disussion
> on
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=102639
> earlier today).
>
> In my case, I wanted to let a pseudo-package require specifically
> "kernel = 2.4.20-18.9", to pull that kernel package in with APT
> (more details on request) and I then detected that "kernel-2.4.20-8"
> was good enough for rpm (and APT) to satisfy "kernel = 2.4.20-18.9".
Feature, or at least necessity for legacy compatibility.
Before rpm-3.0.2, only Requires: and Conflicts: permitted versions.
[...]
And there are even better reasons for not changing rpm's behavior.
Add a file requires on a file in the kernel package that has both the
Version: and Release: appended as suffix, almost every file in the
package as both V-R appended.
I am using this workaround for the kernel modules I build, but it
still does not do an exact nevra dependency, i.e. arch is missing (but
it helped lowering support queries to a minimum, almost nobody has
multiple kernels installed differing only in arch).
Arjan, how about adding a new tag like
Provides: strictdep-kernel[-<flavour>]-%{_target_cpu} =
%{?epoch:%{epoch}:}%{version}-%{release}
and letting kernel modules depend on that?
It won't spoil legacy behaviour and keep kernel module provider happy :)
--
Axel.Thimm(a)physik.fu-berlin.de