DEST_MODULE_LOCATION

Jonathan Archer jon at rosslug.org.uk
Thu Feb 2 06:16:32 CST 2012


Having said that,

The version we are using comes from the RPMForge repository and looks to
be quite out of date.. I've just looked at the /usr/sbin/dkms from the
latest git commit and it seems to have quite a number of differences
around the ADDON_MODULES_DIR.

I know what i'm doing this afternoon :-)

Cheers

Jon
On Thu, 2012-02-02 at 11:36 +0000, Jonathan Archer wrote:
> Hi Ian,
> 
> Thanks for that, but already spotted and tried that... It seems not to
> work as planned, probably the reason its still undocumented and hence
> why I ended up modifying the /usr/sbin/dkms script to incorporate the
> extra variable to override the os check...
> 
> I'm not on that particular workstation at the moment but as soon as I
> can I'll post the changes that I made to here.
> 
> Cheers
> 
> Jon
> 
> On Thu, 2012-02-02 at 10:36 +0000, Ian Abbott wrote:
> > Hi Jon,
> > 
> > The /usr/sbin/dkms script also seems to use an undocumented
> > configuration variable ADDON_MODULES_DIR which AFAICT means you could
> > put ADDON_MODULES_DIR=/foo/bar in your dkms.conf and the modules would
> > be installed to /lib/modules/$kernelver/foo/bar .
> > 
> > Best regards,
> > Ian.
> > 
> > On 2012/02/02 10:06 AM, Jonathan Archer wrote:
> > > OK so I figured a way around this by modifying the OS check function to
> > > include a check for a new variable setting in the dkms.conf file 
> > > 
> > > I specify a variable called OVERRIDE_OS_CHECK in that file, if this is
> > > set to yes then the os check does not run. This being the section which
> > > overrides the destination for the compiled module.
> > > 
> > > Seems to work ok...
> > > 
> > > Cheers
> > > 
> > > Jon
> > > 
> > > 
> > > On Wed, 2012-02-01 at 15:52 +0000, Jonathan Archer wrote:
> > >> Hi Ian
> > >>
> > >> I had thought about that, but thought if there was a way to override the
> > >> setting which was originally there to provide the location where the
> > >> module was placed, that would be a better way forward.
> > >>
> > >> Cheers
> > >>
> > >> Jon
> > >> On Wed, 2012-02-01 at 15:47 +0000, Ian Abbott wrote:
> > >>> On 2012/02/01 03:23 PM, Jonathan Archer wrote:
> > >>>> Hi All,
> > >>>>
> > >>>> This has probably already been covered, but i'm new here so please bear
> > >>>> with me.
> > >>>>
> > >>>> Is there any way to override the DEST_MODULE_LOCATION to not ignore the
> > >>>> configuration specified? as in I know it puts everything in /extra but
> > >>>> for a particular module I'm building it needs to go in a different
> > >>>> location as the absolute path seems to be called from a pre-compiled
> > >>>> binary that we can't modify...
> > >>>>
> > >>>> Cheers
> > >>>>
> > >>>> Jon
> > >>>
> > >>> Would a POST_INSTALL script work, maybe to install a symlink?
> > >>>
> > >>> Unfortunately there is no PRE_UNINSTALL or POST_UNINSTALL hook that
> > >>> could be used to remove that symlink, so you could be left with a
> > >>> dangling symlink on uninstall.  There is a POST_REMOVE hook though.
> > >>>
> > >>
> > >>
> > >> _______________________________________________
> > >> DKMS-devel mailing list
> > >> DKMS-devel at dell.com
> > >> https://lists.us.dell.com/mailman/listinfo/dkms-devel
> > > 
> > > 
> > > _______________________________________________
> > > DKMS-devel mailing list
> > > DKMS-devel at dell.com
> > > https://lists.us.dell.com/mailman/listinfo/dkms-devel
> > 
> > 
> 
> 
> _______________________________________________
> DKMS-devel mailing list
> DKMS-devel at dell.com
> https://lists.us.dell.com/mailman/listinfo/dkms-devel




More information about the DKMS-devel mailing list