DKMS version 0.27.05 is available here.

* Added "mktarball" and "ldtarball". This is for using DKMS within systems management purposes. Instead of having to rebuild modules on every system within your environment, you can now just build the modules on one system and utilize these actions to transport the built modules to your other systems. mktarball makes a tarball for the specified module/module version. This tarball includes the driver source and the built modules for each kernel. Then, ldtarball can be used to load the tarball on any other DKMS tree. This leaves the drivers in the "built" state and then `dkms install` can be used to install the modules in the /lib/modules tree.

* Added the --force option to be used in conjunction with ldtarball. With ldtarball, if it finds module/versions in your tree already, it normally will not overwrite them with the tarball. This can be overrided with the --force option.

* Changed the dkms.conf option of NEEDED_FOR_BOOT to REMAKE_INITRD. It functions just the same and has the same exact behavior. REMAKE_INITRD is just a more intuitive name.

* Added the dkms.conf option of MODULE_CONF_ALIAS_TYPE. This is to handle deficiencies in DKMS's editing of /etc/modules.conf. Rather than having to specify some static line to be added to modules.conf such as "alias scsi_hostadapter99 qla2200_6x", you now should just specify MODULE_CONF_ALIAS_TYPE="scsi_hostadapter". During install, DKMS will then figure out if modules.conf has a reference in it already for your module, and if it doesn't, it will add as the last alias type number (eg. if you have 4 other scsi_hostadapter devices, it will be set as scsi_hostadapter5). Other common ALIAS_TYPEs include "eth" and "sound-slot-".

* When removing modules, alias references in /etc/modules.conf will now remain if the find command can find other instances of that module name within the /lib/modules tree for that kernel. If no other drivers exist, the alias will be removed.

* The DKMS spec file now installs from the tarball instead of just the SOURCEs

Doug Gilbert posted this message on the linux scsi mailing list today. He was playing with devlabel on RH9 with 2.5.68 and devlabel was causing chaos. ...and its not my fault. He issued a patch to the kernel to improve its error handling.