RPM dependency rationale (and kernel packages)?

Jeff Johnson jbj at redhat.com
Wed Aug 20 17:58:24 UTC 2003


On Wed, Aug 20, 2003 at 02:20:33PM +0200, Thomas Vander Stichele wrote:
> 
> > Put needed kernel symbols directly into package Provides: and 3rd party
> > kernel module packaging instantly becomes more reliable.
> 
> You're making me very curious now.   Care to explain this a bit more ?
> :)
> 

Sure. Forgive me if I miss details -- I don't build kernels by choice --
but I'm confident that I have the concepts.

The kernel has an ABI, exported in System.map, used by insmod, to load modules.

In order to produce 3rd party loadable modules outside of the kernel, that
same mechanism and information would have to be sufficiently duplicated into
package metadata so that an insmod failure could be detected at install,
not run time.

Automagically processing System.map and emitting dependency strings ain't
exactly rocket science, that's all that find-requires in rpm has been doing
for years. Hack, works.

For (a totally artificial and probably insane) example, let's say a
kernel module was built against some kernel on a build machine and
needed the symbol (early in System.map was the criteria of choice)
	c0100218 T stack_start
A little bit of sed magic might automagically generate a dependency
like
	Requires: ksym(stack_start)

Then the magic construct "ksym(...)" could grovel through the System.map
(or whatever insmod uses these days) at install time to check to see
whether yes, indeed, there was an already installed kernel that might
satisy each and every symbol.

It's not a whole lot harder to construct a policy driven path for
install if, say, several kernels had the symbols necessary for
insmod functionality, and place the module in the correct /lib/modules
directories. Note plural.

None of the above is impossibly hard to conceive of.

The impediment is more one of GPL ideology, not actually implementation.

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