having a hyphen '-' as part of PACKAGE_VERSION caused strange failures from the resulting deb

[Peter Petrakis]

Previously my config file looked like this:

PACKAGE_NAME="alsa-driver-hda-intel"
# no dashes or underscores allowed, less is more
PACKAGE_VERSION="2.6.32-21"
AUTOINSTALL="yes"
OBSOLETE_BY="2.6.35"

# We've got to build with a extra makefile because
# dkms sources this file, which locks in what pwd
# is and causes all sorts of problems.
#
MAKE="make KVER=$kernelver"
CLEAN="make KVER=$kernelver clean"

BUILT_MODULE_NAME[0]="snd-hda-codec-analog"
BUILT_MODULE_LOCATION[0]="./"
DEST_MODULE_LOCATION[0]="/updates/kernel/sound/pci/hda"

That "-21" wasted many hours of my time. It created a deb that upon installation would claim
that there was no source code present to compile against and wouldn't even install the binaries
I had built for it.

$ sudo dpkg -i alsa-driver-hda-intel-dkms_2.6.32-21_all.deb
...
Selecting previously deselected package alsa-driver-hda-intel-dkms.
(Reading database ... 54571 files and directories currently installed.)
Unpacking alsa-driver-hda-intel-dkms (from alsa-driver-hda-intel-dkms_2.6.32-21_all.deb) ...
Setting up alsa-driver-hda-intel-dkms (2.6.32-21) ...
Loading new alsa-driver-hda-intel-2.6.32 DKMS files...
First Installation: checking all kernels...
Building only for 2.6.32-22-generic
Building for architecture i686
This package appears to be a binaries-only package
 you will not be able to build against kernel 2.6.32-21-generic
 since the package source was not provided
This package appears to be a binaries-only package
 you will not be able to build against kernel 2.6.32-21-generic-pae
 since the package source was not provided

$ dkms status

[no output]

I don't have a root cause as to why the deb thinks it's configured this way. I
removed the "-21" from the version and in return had a fully functioning deb.

[Mario Limonciello (superm1)]

Peter,

There was a massive rewrite of DKMS for bash optimization over the last year. Within this a lot of little weird corner case bugs like this got cleaned up. I actually just tried using a package with a "-" in the name and it appears to handle properly now:

supermario@mlimonciello ~ $ sudo dkms add -m nvidia_bl -v 0.69-1

Creating symlink /var/lib/dkms/nvidia_bl/0.69-1/source ->
                 /usr/src/nvidia_bl-0.69-1

DKMS: add Completed.
supermario@mlimonciello ~ $ sudo dkms install -m nvidia_bl -v 0.69-1

Kernel preparation unnecessary for this kernel. Skipping...

Building module:
cleaning build area....
make KERNELRELEASE=2.6.38-8-generic-pae -C /lib/modules/2.6.38-8-generic-pae/build SUBDIRS=/var/lib/dkms/nvidia_bl/0.69-1/build modules....
cleaning build area....

DKMS: build Completed.

nvidiabl.ko:
Running module version sanity check.
 - Original module
   - No original module exists within this kernel
 - Installation
   - Installing to /lib/modules/2.6.38-8-generic-pae/updates/dkms/

depmod....

DKMS: install Completed.

[Mario Limonciello (superm1)]

(Note this is with Master/2.2.0.x)

[Eduard Hasenleithner (eduard-hasenleithner)]

Is it correct, that this bug still exists in lucid?

[Mario Limonciello (superm1)]

Yes, that's correct. DKMS 2.2.0.x is only on 11.04 and later.

[Eduard Hasenleithner (eduard-hasenleithner)]

Hi Mario

I tried now with dkms 2.2.0.3-1 and I still have the same problem. Looking at your Message #1 I think you did not understand the problem correctly.

The problem is not that the sequence 'dkms add' and 'dkms install' fails. The problem is that when you generate a debian package using 'dkms mkdeb --source-only' you get an error during installation of the resulting package.

[Mario Limonciello (superm1)]

Eduard,

Ok i'll try to investigate more in checking mkdeb.

[Eduard Hasenleithner (eduard-hasenleithner)]

I noticed, that when changing in /etc/dkms/template-dkms-mkdeb/debian/postinst

CVERSION=`dpkg-query -W -f='${Version}' $PACKAGE_NAME | awk -F "-" '{print $1}' | cut -d\: -f2`
  to
CVERSION=`dpkg-query -W -f='${Version}' $PACKAGE_NAME`

the resulting package does work for me.

[Peter Petrakis (peter-petrakis)]

A lot of these errors come down to the fact that DKMS is a meta-package
packager. Unless we're running lintian by default on the resulting output
users will be left to using diving rods to determine what went wrong.

These days, launchpad recipes achieve the same effect
as DKMS while producing a native deb package. So what you learn
can actually be re-applied to native, mainstream packaging.

https://help.launchpad.net/Packaging/SourceBuilds/Recipes

[Darik Horn (dajhorn)]

@peter-petrakis: DKMS rebuilds modules during KBI changes. How does bzr-builder substitute that feature?

I don't see any kernel modules published in the AvailableDailyBuilds list.

[Peter Petrakis (peter-petrakis)]

Why would it need to? It merely needs to track the latest mainline kernel, and autobuild
a new version based on that as a dependency. I don't have the exact magic handy though
I don't see why it wouldn't be possible. If not it would be a valuable feature to add.

BTW
https://wiki.ubuntu.com/Kernel/MainlineBuilds?action=show&redirect=KernelTeam%2FMainlineBuilds

DKMS really benefits OEMs who don't want to maintain repositories, for multiple operating systems,
 for the software they deploy. When your target is solely Ubuntu you have a well defined target,
deb, with a single dependency, the kernel version, why put all this complexity between you
and your software?

So...
https://bazaar.launchpad.net/~ubuntu-branches/ubuntu/quantal/linux-backports-modules-3.2.0/quantal/view/head:/debian/control

Build-Depends: ... linux-headers-3.2.0-24-generic [i386 amd64], linux-headers-3.2.0-24-generic-pae [i386]

What the recipe could do is template the kernel version number in build-depends and
create a new control file via merge and that would trigger a new build. Haven't tried it yet,
but it's more concrete than the hand waving I did in the first para :). Fetching the latest
kernel version from the repo or LP is just a simple matter of programming.

[Eduard Hasenleithner (eduard-hasenleithner)]

Hi Peter

I understand that you are the reporter of this bug, and you have new ideas on how to maintain external kernel modules within ubuntu.

But: There are kernel modules maintained even outside of the ubuntu repository (even outside of launchpad/bzr) as it is in my case. Using DKMS has proven to be very usable for my case, and the problem that is described in the summary of the bug is still present.

So, in my opinion this bug is not the best place to discuss alternative methods of maintaining external kernel modules.

[Matthew Rahtz (chiizufish)]

Eduard's fix of tweaking the CVERSION calculation in postinst seems to work for us too.