Strict kernel module dependencies (was: RPM dependency rationale (and kernel packages)?)

Jeff Johnson jbj at redhat.com
Tue Aug 19 18:12:33 UTC 2003


On Tue, Aug 19, 2003 at 08:49:38PM +0300, Axel Thimm wrote:
> 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 :)

Adding arch to a static provides is insufficient, arch alone is not sufficient
clue. Consider the optional CMOV instruction on i686.

Better is to add a probe dependency, basically the contents of
/proc/cpuinfo with some charatcer adornment, that (and that alone)
starts to provide sufficient granularity to add more precise
dependencies.

Even probe dependencies fail with run-time (i.e. mobo replacement)
changes, however.

There's no easy answer, but more than adding arch to a kernel Provide:
is needed.

73 de Jeff

-- 
Jeff Johnson	ARS N3NPQ
jbj at redhat.com (jbj at jbj.org)
Chapel Hill, NC





More information about the devel mailing list