On Oct 10, 2007, at 11:45 AM, Patryk Zawadzki wrote:
Here's a sample "find-provides" script as proposed by Fedora guys: https://lists.dulug.duke.edu/pipermail/yum-devel/attachments/20070222/3eb6c059/find-provides.obj The proposition is to include it in all rpm-based distros. What it does is simple - for each kernel module add Provides with a matching modalias. The goal is to allow managers like poldek to automatically find needed packages for detected hardware. More background: https://lists.dulug.duke.edu/pipermail/yum-devel/2007-February/003233.html
Note that find-provides scripts are not invoked by rpm unless AutoReqProv: no
is specified, which has additional consequences for multilib packaging. The find-provides scheme "works" only for kernels. Do you really want or need to remap modules compiled into the kernel (or kmod additional drivers) automagically?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)
But additional semantic conventions would need to be added to poldek
and other depsolvers. I'm not sure the conventions proposed by Fedora
are any better (or worse) than other conventions. For one thing, Fedora
appears to be on a "No kernel module packages." agenda.
Specifying a provides for a kernel module is rather different than
supplying
a provides for actual hardware. Module dependencies could also be mappedinto file dependencies if the path were globbed; the kernel version in the path is all that prevents a file path from serving in lieu of a module dependency.
rpm already has file probes that look like
Requires: exists(/path/to/somewhere)
Adding a glob on path, and generalizing the access(2) test to be a loop
over all globbed results would be the approach I would take instead.
73 de Jeff
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ pld-devel-en mailing list [email protected] http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
