Bug#454431: debian-policy: Policy for module sources needed
Package: debian-policy Severity: normal I think we should have policy for module source packages that specifies how such a package should look like. There are several ways to build a kernel module from a source file and some (at least the inclusion in linux-modules-extra/contrib/non-free) are not easily tryable by the maintainer of the source package. The current policy in linux-modules-* is: A module source package works with l-m-e, or it doesn't. So I gather it's the source maintainer's job to make sure it compiles inside the framework. But there is no documentation available about linux-modules-* at all. The process might change again in the future which might make the situation even more complex. Therefore I think there should be some (sub) policy explaining what to do. Michael -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (x86_64) Kernel: Linux 2.6.22-3-amd64 (SMP w/2 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#454431: debian-policy: Policy for module sources needed
Hi, On Wed Dec 05, 2007 at 12:06:34 +0100, Michael Meskes wrote: Package: debian-policy Severity: normal I think we should have policy for module source packages that specifies how such a package should look like. There are several ways to build a kernel module from a source file and some (at least the inclusion in linux-modules-extra/contrib/non-free) are not easily tryable by the maintainer of the source package. The current policy in linux-modules-* is: A module source package works with l-m-e, or it doesn't. So I gather it's the source maintainer's job to make sure it compiles inside the framework. But there is no documentation available about linux-modules-* at all. The process might change again in the future which might make the situation even more complex. Therefore I think there should be some (sub) policy explaining what to do. Michael *seconded* -- [EMAIL PROTECTED] /root]# man real-life No manual entry for real-life -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
