This is to work around a validation issue that arises under the 3.x future
parser, as proper numeric types have been introduced (ie, not all scalar values
are strings). Users have come to expect to to be able to pass in unquoted
integer values to the order parameter which will fail to validate as a string
when the future parser is enabled.
Partially reverting the $warn/$warn_message param split from eaf8407 as this
change was unnecessarily API breaking. Instead, we are adding string/bool type
validating to the $warn parameter and deprecation warnings for the usage of
stringified boolean values (eg, 'true', 'on', etc.). In a future major release,
the logic can be simplified to treating all string values as a warning message.
There's no need to allow the ownership/permissions of a fragment to be set as
the concat define sets ownership/permissions on the final aggregated file.
Revert validation of the target param as an absolute path and allow it to be an
arbitrary string. This is so the
concat { <foo>: path => ... }
concat::fragment { ...: target => <foo> }
association may be symbolic as long as concat path param is specified. This
should resolve the symbolic name regression introduced in:
https://github.com/puppetlabs/puppetlabs-concat/commit/eaf84079
The use of $::id to set the default user/owner and group has caused
multiple bugs in the past, is incorrectly used to infer the egid,
introduces a dependency on the `id` fact, and provides no functionally
that can't be accomplished by passing `undef` or not setting the
respective params on the file & exec types.
A possible alternative would be to introduce a dep on the $::gid fact
but that would mean the entire module would depend on a version of
facter than hasn't shipped yet (unworkable) or to add a gid/egid fact
into this module (ugly).
