Add parameter update_command_path

[treydock]

Add update_command_path parameter that defaults value is the value of $update_command
Allows a custom update command to be used that is more than just the path to wrapper script

[adamcrews]

I'm not opposed to this, but I don't understand the use case. Why would you want to run the update command with different arguments than what is found in the config file? The update command is only executed upon package install, so my assumption is that the update command should run the same way it will run out of the update schedule.

The way I would approach this sort of issue would be to have some profile code that turns off the update on install, then runs the custom command.

In lieu of that, I think it might be better to rework this to have the update command accept an argument, rather than completely replace the command.

[treydock]

The use case is sort of unique. I have Puppet managing systems that are NFS root and this NFS root system is the read/write host for read-only NFS systems. The read-only systems can't run updatedb since /var/lib/mlocate is read-only. The cron task will exist on read-only systems but I use some custom facts and logic to prevent the cron task from running:

  $update_command_path = hiera('mlocate::update_command_path', '/usr/local/bin/mlocate.cron')

  # Do things a bit differently on nfsroot RW hosts
  if str2bool("$::nfsroot") and ! str2bool("$::nfsroot_ro") {
    $_update_command = "[ \"x$(facter -p osc_host_type)\" = \"xrw\" ] && ${update_command_path}"
  } else {
    $_update_command = undef
  }

  class { '::mlocate':
    update_command => $_update_command,
  }

[treydock]

Rebased pull request