Re: The PCMCIA and kernel packages

[Manoj Srivastava <srivasta@pilgrim.umass.edu>]

Hi,
The Proposal:

>>"Brian" == Brian Mays <bem5r@virginia.edu> writes:
Brian> Sounds great.  Let me check the details.  A stand-alone modules
Brian> (SAM) package (e.g., pcmcia-cs) would have a binary deb file
Brian> (pcmcia-cs<version and arch>.deb) and a source deb file
Brian> (pcmcia-source<version and arch>.deb).  The source deb file
Brian> would unpack itself into the /usr/src directory and
Brian> symbolically link its directory into the /usr/src/modules
Brian> directory.

	Exactly.

Brian> When the kernel debian.rules is given the target "modules," it
Brian> would build new binary packages for all of the packages in
Brian> subdirectories of the /usr/src/modules directory.  The rule
Brian> given above should work fine except that I would suggest that
Brian> "KVERSION" be used as the variable for the kernel version, to
Brian> distinguish it from the package version, and the "binary" rule
Brian> (or perhaps a "kernel" rule to indicate that it is being
Brian> compiled for a specific kernel source) be used instead of
Brian> "dist."  There is no need to make a new tar and diff file,
Brian> since all that needs to be done is recompile the modules so
Brian> that they will be compatible with the new version of the
Brian> kernel.

	I agree about the version and the target name, but I think
 that the tar and diff files may be required, maybe there should be
 two sets of targets, one for just the binary .deb file, and another
 for the whole shebang (what is the etymology of this word?) -- and
 what about the version number of the module packages produced? should
 it not also be bumped up? The scenario could be 
   Day 1: module X created with verion 3.1.2-0 and uploaded to master.
   Day 3: the kernel version changes, and a new module package is
          created. No changes made to the module; so what should the
          version be? if it the same, then there will be confusion on
          the archives.

 Workaround? put the kernel version in the module name. So, we have
 pcmcia-cs-2.0.0_3.1.2-0_i386.deb, no confusion about which kernel it
 belongs to, and the preinstall scripts warn if the running kernel is
 not the correct one.

Brian> Since the kernel version number is being passed to the
Brian> debian.rules makefile, the SAM package would know to use the
Brian> kernel source in the
Brian> /usr/src/kernel-source-$(KVERSION) directory when compiling its
Brian> modules.  However, when no KVERSION variable is provided,
Brian> (when, for example, a user wants to add a stand-alone module
Brian> package to his own custom compiled kernel, so he simply types
Brian> "./debian.rules binary") the SAM package would use the kernel
Brian> source in the /usr/src/linux directory.

	Hmm, you can't really make an assumption about the location of
 the sources. How about this where KVERS contains the kernel version,
 and KSRC the full path name of the top level kernel source directory.

# only generate module image packages
modules_image:
        for $$module in $(MODULE_LOC)/* ; do \
            (cd $$module; \
              ./debian.rules KVERS=$(version) KSRC=$(SRCTOP) kdist_image; ) \
        done

# generate the modules package and sign them with dchanges
modules:
        for $$module in $(MODULE_LOC)/* ; do \
            (cd $$module; \
              ./debian.rules KVERS=$(version) KSRC=$(SRCTOP) kdist; ) \
        done

	manoj
-- 
 Any clod can have the facts, but having opinions is an Art. Mencken
 [Having the facts is hard.  --ed]
Manoj Srivastava               Systems Research Programmer, Project Pilgrim,
Phone: (413) 545-3918                A143B Lederle Graduate Research Center,
Fax:   (413) 545-1249         University of Massachusetts, Amherst, MA 01003
<srivasta@pilgrim.umass.edu> <URL:http://www.pilgrim.umass.edu/%7Esrivasta/>