Supported hardware info in PLD rpms?

[Jeff Johnson]

On Oct 10, 2007, at 12:31 PM, Patryk Zawadzki wrote:

> 2007/10/10, Jeff Johnson <n3npq at mac.com>:
>> If you really want dependencies on hardware, then /sys or /proc file
>> info
>> should be directly mapped into a run-time dependency probe as a
>> Provides:.
>> E.g. The contents of /proc/modules might be used to satisfy a
>>     Requires: procmodules(bluetooth)
>> for systems actually using bluetooth. And the dependency can be made
>> "soft" by specifying as
>>     Requires(hint): procmodules(bluetooth)
>
> The idea is the other way around: for given hardware find all relevant
> packages (kernel-net-* for example) that provide support for the
> hardware. So each kernel module Provides the modaliases for supported
> hardware and poldek can ask "which module handles my obscure wifi card
> with modprobe id XXXXXXX?"
>

I would still solve the problem with run-time probes rather than  
additional
Provides: added to kernel-module-* packaging.

The problem with the example that you give
     "which module handles my obscure wifi card"
is that there will likely already be some older kernel
packaging that already supplies the added Provides: statically. So
more than just adding a Provides: to kernel module packaging
is needed, a means to prefer one Provides: over another is
additionally needed by poldek or other depsolver.

What is additionally needed is the dynamic set of Requires:
for the hardware present on the system run against a set of
kernel and kernel-module packages to insure that
an upgrade with new kernel (and kernel module)
packages supports the same hardware.

Plug in new hardware, and a new
	Requires: modalias(foo)
should magically appear imho.

(aside) The inventory of "available" hardware assumes that the
obscure wifi card is plugged in, and recognized somehow, which
likely already assumes a pre-existing matching Provides:  ... but I  
digress.

The discovery of which package contains the driver for
the "obscure wifi card" is only part of the problem.

Hmmm time to think a bit ...

73 de Jeff
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2205 bytes
Desc: not available
Url : /mailman/pipermail/pld-devel-en/attachments/20071010/732fa539/attachment.bin