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

[Axel Thimm]

On Tue, Aug 19, 2003 at 02:12:33PM -0400, Jeff Johnson wrote:
> On Tue, Aug 19, 2003 at 08:49:38PM +0300, Axel Thimm wrote:
> > 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.

The Red Hat kernel model already takes care of that. Since arch alone
cannot describe the properties of the kernel a flavour was invented
and shoved into the kernel rpm name. I.e. Red Hat builds not for
archs, but for (arch, flavour) tuples, where flavour is one of smp,
bigmem, jensen, enterprise, etc.

This tupel defines the used .config file which contains all the
required information (including a cmov* enabled kernel or other fancy
stuff).

Depending on the impact of a difference like cmov* one would consider
a new arch, or simply a new flavour (or even simpler discard the extra
instructions).

> 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.

This would munge the separation of build and target hosts. It would be
alright for custom kernels, where build host = target host, but not
for providing third party kernel modules package in rpms and matching
a set of kernel rpms. But you have this information in the (arch,
flavour) tuple.

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

If Red Hat doesn't change the current (arch, flavour) policy (and
there is no reason to) the suggested Provides would suffice for exact
kernel module dependencies.
-- 
Axel.Thimm at physik.fu-berlin.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20030820/39fd7c3d/attachment-0002.bin