DEST_MODULE_LOCATION

Jonathan Archer jon at rosslug.org.uk
Thu Feb 2 04:06:54 CST 2012


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




More information about the DKMS-devel mailing list