Loïc Minier wrote:
Do I understand correctly that you try to make-kpkg the modules and not
the kernel? This seems broken to me.
I manually download upstream kernel sources, untar them in /usr/src and
symlink /usr/src/linux-[kernelversion] to /usr/src/linux, configure,
build, install and load them at bootup with grub or lilo. Then I'd
install [driver]-source, such as madwifi and fglrx, and use
module-assistant to build those. For fglrx and, as testing examples,
ipw2100 and ndiswrapper, this works flawlessly. For madwifi, this leads
to a problem because madwifi depends on
[kernel|linux]-image-[kernelversion] which isn't installed.
Why would that be broken in and of itself? If it were, then the
generated binary module packages for fglrx, ipw2100 and ndiswrapper
should be broken due to this dependancy issue, but they do work since
they do *not* depend on the make-kpkg generated kernel image.
What you can not do is combine a custom kernel with make-kpkg-ed
modules or module-assistant-build modules. This seems a very minor
constraint to me and even makes sense -- even if we could technically
imagine detecting whether this is a make-kpkg-ed kernel or a
manually-built kernel and generate or not a dependency.
As of right now, I can, without a doubt, build a custom kernel which
isn't generated with make-kpkg and installed with dkpg, and then use
module-assistant to compile and generate Debian packages for certain
drivers. I've been doing this for some time now. Try it for yourself
with the example modules; I'm only guessing that there's many more
modules which would work the same way, and others who would depend on
the kernel image like madwifi.
My whole point is that there is a *difference* between how
[driver]-source package A works compared to how B works. Even though one
could state that the use of module-assistant together with a custom
compiled kernel (not make-kpkg) is fubar, then there's still the
discrepancy on whether these generated [driver]-modules-[kernelversion]
depend on the [linux|kernel]-image-[kernelversion] package or not.
You can reassign this bug to module-assistant if you want, as I believe
that there's where the policy should be defined. In
/usr/share/doc/module-assistant/HOWTO-DEVEL there are no explicit
statements whether the dependancy should or shouldn't be there. I
believe that it should state this, so that there will be uniformity
amongst kernel module packages. Then it's going to be clear-cut to say
that custom kernels are not supposed to mix with module-assistant
generated module packages, but as of right now this isn't the case.
Regards,
infernix
