Getting module name and version from a DKMS package

Fri Sep 12 01:22:00 2003

Thanks Gary for making these changes. I will update my
code accordingly.

You wrote:

 >>As for unpack, this is interesting but perhaps more
 >>complicated than it
 >>seems.  Depending on how the tarball is put together, there
 >>are various ways
 >>it may decompress.  In the end, dkms will expect the source to be in
 >>/usr/src/<PACKAGE_NAME>-<PACKAGE_VERSION>/ but untarring it in that
 >>directory won't necessarily assure this.

Actually this is another issue I'm facing. DKMS expects the
sources and the dkms.conf file to be under /usr/src/<pkg>-<version>.
I can copy the dkms.conf file contained in a DKMS package to
/usr/src/<pkg>-<version> all right.
But how about the sources? Can I assume there's only one tar
gzip'd file in a DKMS package, and that this file contains the
module sources?

Then I can run: tar zxf <source tarball> -C /usr/src/<pkg>-<version>
to get the sources in the right place. However if the sources
tarball contains a subdir then it'll be created under
/usr/src/<pkg>-<version>. Is is safe to assume that the module
author will have written the dkms.conf file accordingly, i.e.
that the MAKE=<command> in the dkms.conf will take care of
cd'ing into the proper subdir under /usr/src/<pkg>-<version>?

Perhaps by adding certain conventions like e.g. the name of
the sources tarball contained in a DKMS package, it would be
easier to implement something like an "unpack" command?

Setting gmodconfig aside for a minute, DKMS end-users have
several steps to do manually before installing a DKMS package:
- gunzip, untar the package file
- figure out the package name and version
- find the sources tarball, and run:
   tar zxf <source tarball> -C /usr/src/<pkg>-<version>
- cp dkms.conf /usr/src/<pkg>-<version>

These steps are simple (but not fun to type for each module to
install!), and yet a typo in a package name or a version number
might silently wreck havoc on the DKMS tree and cause problems
later. So IMHO they should really be automated. What do you think?

Cyril

Gary_Lerhaupt@dell.com wrote:
> Done.  DKMS 0.35.01 is now available.
> 
> ChangeBlog: http://www.lerhaupt.com/foo/archives/000125.html
> 
> Gary
> 
> 
>>-----Original Message-----
>>From: Gary_Lerhaupt@dell.com [mailto:Gary_Lerhaupt@dell.com]
>>Sent: Wednesday, September 10, 2003 11:56 AM
>>To: borto@users.sourceforge.net; dkms-devel@dell.com
>>Subject: RE: Getting module name and version from a DKMS package
>>
>>
>>Thanks Cyril.  gmodconfig is pretty slick, and I could see 
>>that these could
>>be stumbling blocks for you.
>>
>>I'm going to go ahead and implement PACKAGE_NAME= and 
>>PACKAGE_VERSION= to
>>the list of directives parsed for in a dkms.conf.  Even 
>>though dkms will not
>>make direct use of them, I will make this a strict 
>>requirement such that
>>dkms will refuse to function without some value for these.  I 
>>should note
>>that this means an added responsibility for developers as 
>>they will not just
>>be able to take a dkms.conf from one version of their module 
>>and directly
>>copy it to the next version.  They'll need to now bump the 
>>PACKAGE_VERSION.
>>Of course, if they fail to do this, I'm not sure there is 
>>much recourse for
>>gmodconfig as you'll depend on them for this.
>>
>>As for unpack, this is interesting but perhaps more 
>>complicated than it
>>seems.  Depending on how the tarball is put together, there 
>>are various ways
>>it may decompress.  In the end, dkms will expect the source to be in
>>/usr/src/<PACKAGE_NAME>-<PACKAGE_VERSION>/ but untarring it in that
>>directory won't necessarily assure this.  
>>
>>Gary
>>
>>
>>>-----Original Message-----
>>>From: Cyril Bortolato [mailto:borto@users.sourceforge.net]
>>>Sent: Wednesday, September 10, 2003 1:11 AM
>>>To: dkms-devel@dell.com
>>>Subject: Getting module name and version from a DKMS package
>>>
>>>
>>>Hi,
>>>I'm writing a tool called gmodconfig which uses DKMS as
>>>a back-end to install kernel modules.
>>>
>>>Once a DKMS package has been downloaded (for details on how
>>>gmodconfig does that see http://gmodconfig.sourceforge.net/),
>>>the right thing to do would be to execute these commands:
>>>
>>>dkms add -m <module> -v <version>
>>>dkms build -m <module> -v <version> -k <kernel-version>
>>>dkms install -m <module> -v <version> -k <kernel-version>
>>>
>>>However once a DKMS tarball has been downloaded, I don't
>>>have a way to extract the module name and version from it.
>>>As a result I can't run the above dkms commands which
>>>require these 2 pieces of informations.
>>>
>>>I could parse the name of the package file, but it may or
>>>may not be reliable. Your example package is called
>>>qla2x00-clariion_dkms-v6.04.00.tar.gz but in the install.sh
>>>the DKMS module name appears to be "qla2x00", and not
>>>"qla2x00-clariion".
>>>
>>>Gmodconfig might be able to infer the module name and version
>>>if users initiate a DKMS install from the "Updates" tab of
>>>a module (see screenshots or doc). But it might not always
>>>work: your example package really contains 2 modules "qla2200"
>>>and "qla2300", and the DKMS module is called "qla2x00".
>>>And users are given the ability to install any DKMS package
>>>they want, out of the blue (see Install menu).
>>>
>>>My suggestion is to store the DKMS module name and the version
>>>inside the dkms.conf file of a package. That way I can have
>>>access to these data reliably.
>>>
>>>Actually it'll be nice to provide a new command e.g. "unpack"
>>>whose syntax would be something like:
>>>dkms unpack <package file>
>>>
>>>This command would create the /usr/src/<module>-<version>
>>>directory, do the gunzip and tar extraction of the sources
>>>and copy the dkms.conf file, i.e basically do what lines 15-25
>>>in the install.sh script of the qla2x00-clariion_dkms-v6.04.00
>>>package do. These commands can really be automated and grouped
>>>together into one DKMS command, IMHO.
>>>
>>>Cyril
>>>