Enhancements to simplify creation/maintenance of dkms packages

Registered by Steve Magoun on 2011-10-27

Discuss and implement in Ubuntu a framework for generating dkms packages from a driver source tarball. The framework makes it easier to create an maintain dkms packages by automating many of the mechanical tasks currently required by dkms.

Blueprint information

Status:
Not started
Approver:
Steve Langasek
Priority:
Undefined
Drafter:
Christopher Townsend
Direction:
Needs approval
Assignee:
Christopher Townsend
Definition:
New
Series goal:
Proposed for precise
Implementation:
Unknown
Milestone target:
milestone icon ubuntu-12.04-beta-1

Sprints

Whiteboard

For work within Canonical, have a framework for creating DKMS deb packages - auto-generates dkms.conf and other packaging. Does not use dh_dkms. Aim is to make this public and improved.

David Henningson uses a variant to create an Alsa Crack-of-the-day DKMS snapshot dkms package via a recipe (https://code.launchpad.net/~ubuntu-audio-dev/+recipe/alsa-driver-daily) which merges dkms packaging with the upstream ALSA source.

The existing framework can create FISH packages (Specific to Dell installation process), which has been stripped out of the following branch, showing the existing framework: bzr branch lp:~townsend/+junk/auto-dkms-framework

Framework currently has a script to determine what the .ko files produced are. It may be possible to move this logic into dkms.

For the ALSA dkms package, extra logic is necessary for fetching source etc.. It would be good if the framework were flexible enough to facilitate this, therefore we should consider some sort of plugin option to allow this sort of extra processing. E.g. David's specific can be handled by including his make rules into main Makefile

Could be useful to check dkms.conf for errors, but as files become auto-generated this may be less important.

Agreed Aims:
- incorporating dh_dkms
   openafs in Ubuntu uses dh_dkms
- merging smarts from the framework into dkms package itself (e.g. the script to determine which modules are created)
   * follow dh model for helper scripts, create man pages too
- potentially creating dkms.conf from within dkms itself in the simple scenarios
- Remove non-functional OBSOLETE_BY directive in next dkms version and when framework is merged
- Document and publish new workflow: blog.canonical.com?

(?)

Work Items