Re: Kernel module package depending on kernel-headers.
Ian> The problem I have with the Debian module setup is that the
Ian> resulting binary package is made to depend on the _exact_ kernel
Ian> version (x.y.zz). I know some modules require this, but most do
Ian> not (after all, this is why we have MODVERSIONS, or?), so this is
Ian> a waste of resources.
Manoj> But I guess it is easier to bitch about the infrastructure
Manoj> rather than figure out how to work with it.
I didn't mean to "bitch" - I am sincerely sorry if it sounded that
way. This is a really hard problem, given that "upstream" in this
case is the union of the kernel hacker and module hacker collections.
Manoj> Have you ever gotten that to work? I never have actually seen a
Manoj> working multiple kernel version module in the wild.
Sure. compressed loop and lmsensors, both seem to work with (at
least) 2.4.16 through 2.4.19 without recompile. I remember in the bad
old days ftape also lasted me quite long. And while I never tried to
maintain alsa this way (I dumped it and switched to OSS before I
started compiling modules myself again), I don't get the impression
that its authors expect it to be recompiled with each kernel
patchlevel upgrade.
I know there are modules which are tighly coupled with the kernel and
must be always recompiled, like the various trace kits. But I think
they are the minority.
Manoj> And you can set up your module postinst to install the module
Manoj> in any directory you want -- /lib/modules/2.4/foo, for example,
Manoj> and copy files at will.
But what is the point of having them in a package, then?
Manoj> The modules people can add a postinst hook into the kernel
Manoj> image (by adding to /etc/kernel-img.conf) to have their script
Manoj> called whenever a new kernel image is installed -- and todo
Manoj> this magic, so that the kernel knows to load the module. Or
Manoj> thet can add to the search path for kernel when it looks for
Manoj> the modules.
Okay, I didn't know about the first part, thanks for pointing it out.
But it would only be of any import if the rigid dependencies were
relaxed.
--
Ian Zimmerman, Oakland, California, U.S.A.
GPG: 433BA087 9C0F 194F 203A 63F7 B1B8 6E5A 8CA3 27DB 433B A087
EngSoc adopts market economy: cheap is wasteful, efficient is expensive.
Reply to: