Difference between revisions of "Kernel module package guidelines"

From ArchWiki
Jump to: navigation, search
m (add tag i18n)
m (use sentence case in section headings)
(9 intermediate revisions by 5 users not shown)
Line 1: Line 1:
{{Stub}}
+
[[Category:Package development]]
[[Category:Package development (English)]]
+
[[Category:Kernel]]
[[Category:Guidelines (English)]]
+
[[it:Kernel Module Package Guidelines]]
[[Category:Kernel (English)]]
+
{{Package Guidelines}}
  
{{i18n|Kernel Module Package Guidelines}}
+
{{Expansion}}
  
== Package Separation ==
+
== Package separation ==
 
+
Packages that contain [[kernel modules]] should be treated specially, to support users who wish to have more than one kernel installed on a system.
Packages that contain kernel modules should be treated specially, to support users who wish to have more than one kernel installed on a system.
+
  
 
When packaging software containing a kernel module and other non-module supporting files/utilities, it is important to separate the kernel modules from the supporting files.
 
When packaging software containing a kernel module and other non-module supporting files/utilities, it is important to separate the kernel modules from the supporting files.
  
=== Guideline ===
+
=== Guidelines ===
 +
When packaging such software (using the [[NVIDIA]] drivers as an example) the convention is:
  
When packaging such software (using the NVidia drivers as an example) the convention is:
+
* create an {{Ic|nvidia}} package containing just the kernel modules built for the vanilla kernel
 
+
* create an {{Ic|nvidia-utils}} package containing the supporting files
* create an nvidia package containing just the kernel modules built for the vanilla kernel
+
* make sure {{Ic|nvidia}} depends on {{Ic|nvidia-utils}} (unless there's a good reason not to do so)
* create an nvidia-utils package containing the supporting files
+
* for another kernel like {{Ic|kernel26-mm}}, create {{Ic|nvidia-mm}} containing the kernel modules built against that kernel which provides nvidia and also depends on {{Ic|nvidia-utils}}
* make sure nvidia depends on nvidia-utils (unless there's a good reason not to do so)
+
* make sure {{Ic|nvidia depends}} on the current major kernel version, for example:
* for another kernel like kernel26-mm, create nvidia-mm containing the kernel modules built against that kernel which provides nvidia and also depends on nvidia-utils
+
* make sure nvidia depends on the current major kernel version, for example:
+
 
  depends=('kernel26>=2.6.24-2' 'kernel26<2.6.25-0' 'nvidia-utils')
 
  depends=('kernel26>=2.6.24-2' 'kernel26<2.6.25-0' 'nvidia-utils')
Note that it is 2.6.24-2, not -1 in above example - this is because there was a configuration change to important kernel subsystem that required all modules to be rebuilt. You should always change depends version in such cases, otherwise some people with out-of-sync kernel and module version will report that module is broken.
+
Note that it is {{Ic|2.6.24-2}}, not {{Ic|-1}} in above example - this is because there was a configuration change to important kernel subsystem that required all modules to be rebuilt. You should always change depends version in such cases, otherwise some people with out-of-sync kernel and module version will report that module is broken.
  
 
=== Rationale ===
 
=== Rationale ===
 
 
While kernel modules built for different kernels always live in different directories and can peacefully coexist, the supporting files are expected to be found in one location. If one package contained module and supporting files, you would be unable to install the modules for more than one kernel because the supporting files in the packages would cause pacman file conflicts.
 
While kernel modules built for different kernels always live in different directories and can peacefully coexist, the supporting files are expected to be found in one location. If one package contained module and supporting files, you would be unable to install the modules for more than one kernel because the supporting files in the packages would cause pacman file conflicts.
  
 
The separation of modules and accompanying files allows multiple kernel module packages to be installed for multiple kernels on the same system while sharing the supporting files among them in the expected location.
 
The separation of modules and accompanying files allows multiple kernel module packages to be installed for multiple kernels on the same system while sharing the supporting files among them in the expected location.
  
== File Placement ==
+
== File placement ==
 
+
If a package includes a kernel module that is meant to override an existing module of the same name, such module should be placed in the {{Ic|/lib/modules/2.6.xx-ARCH/updates}} directory.  When '''depmod''' is run, modules in this directory will take precedence.
If a package includes a kernel module that is meant to override an existing module of the same name, such module should be placed in the <code>/lib/modules/2.6.xx-ARCH/updates</code> directory.  When <code>depmod</code> is run, modules in this directory will take precedence.
+

Revision as of 15:37, 27 May 2013

Template:Package Guidelines

Tango-view-fullscreen.pngThis article or section needs expansion.Tango-view-fullscreen.png

Reason: please use the first argument of the template to provide a brief explanation. (Discuss in Talk:Kernel module package guidelines#)

Package separation

Packages that contain kernel modules should be treated specially, to support users who wish to have more than one kernel installed on a system.

When packaging software containing a kernel module and other non-module supporting files/utilities, it is important to separate the kernel modules from the supporting files.

Guidelines

When packaging such software (using the NVIDIA drivers as an example) the convention is:

  • create an nvidia package containing just the kernel modules built for the vanilla kernel
  • create an nvidia-utils package containing the supporting files
  • make sure nvidia depends on nvidia-utils (unless there's a good reason not to do so)
  • for another kernel like kernel26-mm, create nvidia-mm containing the kernel modules built against that kernel which provides nvidia and also depends on nvidia-utils
  • make sure nvidia depends on the current major kernel version, for example:
depends=('kernel26>=2.6.24-2' 'kernel26<2.6.25-0' 'nvidia-utils')

Note that it is 2.6.24-2, not -1 in above example - this is because there was a configuration change to important kernel subsystem that required all modules to be rebuilt. You should always change depends version in such cases, otherwise some people with out-of-sync kernel and module version will report that module is broken.

Rationale

While kernel modules built for different kernels always live in different directories and can peacefully coexist, the supporting files are expected to be found in one location. If one package contained module and supporting files, you would be unable to install the modules for more than one kernel because the supporting files in the packages would cause pacman file conflicts.

The separation of modules and accompanying files allows multiple kernel module packages to be installed for multiple kernels on the same system while sharing the supporting files among them in the expected location.

File placement

If a package includes a kernel module that is meant to override an existing module of the same name, such module should be placed in the /lib/modules/2.6.xx-ARCH/updates directory. When depmod is run, modules in this directory will take precedence.