Steinar H Gunderson <[EMAIL PROTECTED]> writes: > On Thu, Aug 24, 2006 at 07:26:04PM -0300, Fabricio aybabtu Cannini wrote:
>> I'm really a noob when it comes to the kernel guts, but i wonder, can't >> it be made like updating /boot/grub/menu.lst with a new kernel version >> ? > Yes, you could in theory compile a kernel module package from another > package's postinst, but: > 1. You would have to guarantee the right kernel headers are installed at the > time. (You can't install them either, see the next point.) > 2. You cannot install it, as you can't call dpkg from a postinst script, > and dpkg does not yet have any “trigger” functionality that would run > afterwards. There's a more fundamental problem here, which is that we're not Gentoo. There's no reason why a Debian system should have to have a compiler installed. We have buildd farms to do that work for our users. I'd really like to find a way where that applies to kernel modules as well without the pain that we have right now. Unfortunately, while I appreciate people working on this problem, creating a combined package of out-of-tree kernel modules isn't really a solution. Some out-of-tree kernel modules are large and complex and can't easily just be dropped into that sort of shared tree. What we need is some way of correctly expressing the kernel module class of packages in the archive software, with automatic removal of packages for old versions of the kernel, automatic auto-building of the source package against new versions of the kernel when they appear (and new variants), and a way of handling those packages that doesn't mean source changes and a trip through NEW every time the list of kernel variants changes. This isn't easy, which is why it hasn't been done yet, but it's really the right approach. -- Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
