Add a params.pp file #59
Conversation
|
A little addition, introducing the $binary_indicator in params.pp, since the hash commands on OpenBSD don't distinguish between binary and text files. |
|
Sorry for the very long delay. Could you rebase this on master please? |
here, and include it in init.pp archive defined type, and make
sure with an order, that it is instantiated in the catalog
before the defined type is executed.
The order of evaluation in the catalog is ensured by the
include line in init.pp, and the following two lines,
setting the order.
The defined variables specific for OpenBSD are:
$tarcmd string, defining a shell command to run tar
$digest_types hash, defining the supported hash types, and their
shell commands
The $tarcmd is used in extract.pp, the $digest_types is used
in download.pp
The only extra ::osfamily is OpenBSD, the rest is the values
taken in the default: case of the case statement.
The change in download.pp, uses the keys() function from stdlib.
Because of that, stdlib is added as dependency to metadata.json,
and .fixtures.yml. I chose an arbitrary version as minimal version
not too old, and not too recent. Otherwise, stdlib 3.X should
also work.
Added OpenBSD to the metadata.json, in order to get the specs
covering it too.
|
nevermind, rebased ;) Had to add a case statement for Solaris now to the params.pp, where I set the gtar command as in OpenBSD, and the supported hashes as in the default section of the case statement. Let me know if that's ok, or something should be changed, or maybe squashed. |
buzzdeee
force-pushed
the
master
branch
2 times, most recently
from
11dc7b2 to
d75c797
Compare
The hash commands on OpenBSD don't distinguish between binary and text files, so they don't handle the '*' in front of the file name to be checked. additionally update metadata.json for more current OpenBSD versions
buzzdeee
force-pushed
the
master
branch
2 times, most recently
from
4231b94 to
88fb2cf
Compare
| ) { | ||
|
|
||
| require ::archive::params |
There was a problem hiding this comment.
There's no resources in params, so include will do just the same as require.
There was a problem hiding this comment.
I'm not exactly sure about that one. Does an include enforce order of evaluation?
the require ensures ::archive::params is evaluated before the extract.pp is evaluated, so that the
values of ::archive::params::FOOBAR are available, when used later in the defined type, does the
include enforce the same?
There was a problem hiding this comment.
You're mixing up order of parsing and order of evaluation.
Parsing is done on the master side, always top-down.
Evaluation is done on the agent, based on the catalog, and following the dependency tree based on either implicit or explicit dependencies between resources.
The params class has no resources at all, only variables, so there's no need for evaluation ordering. Variables will be available if they have been parsed before, which is true if you included the class already.
|
I changed the require to includes, as well as add a test for the parameter and the variable, and used the fail() function. I hope that is as it was meant. Otherwise let me know. In case everything is fine, squash? |
| if $root_dir { | ||
| $extract_dir = "${target}/${root_dir}" | ||
| } else { | ||
| $extract_dir = "${target}/${name}" | ||
| } | ||
|
|
||
| if ! $tar_command and ! $::archive::params::tarcmd { | ||
| fail("${module_name}: parameter \$tar_command not specified and \$::archive::params::tarcmd not found") |
There was a problem hiding this comment.
If you include archive::params on line 47, there's no reason why you would get in a fail situation here. However, if you use $::archive::params::tarcmd as the default value for $tar_command, then you can check that $tar_command is indeed defined here and fail otherwise, and then you don't need the $real_tar_command variable below.
| @@ -44,7 +44,7 @@ | |||
| $tar_command=$::archive::params::tarcmd, | |||
| ) { | |||
|
|
|||
| include ::archive::params | |||
| require ::archive::params | |||
There was a problem hiding this comment.
No, really. include is all you need. If it fails, it must be another reason.
in order to allow OS specific differences to be set
here. It's included in init.pp archive defined type, and make
sure with an order, that it is instantiated in the catalog
before the defined type is executed.
The order of evaluation in the catalog is ensured by the
include line in init.pp, and the following two lines,
setting the order.
The defined variables specific for OpenBSD are:
$tarcmd string, defining a shell command to run tar
$digest_types hash, defining the supported hash types, and their
shell commands
The $tarcmd is used in extract.pp, the $digest_types is used
in download.pp
The only extra ::osfamily is OpenBSD, the rest is the values
taken in the default: case of the case statement.
The change in download.pp, uses the keys() function from stdlib.
Because of that, stdlib is added as dependency to metadata.json,
and .fixtures.yml. I chose an arbitrary version as minimal version
not too old, and not too recent. Otherwise, stdlib 3.X should
also work.
Added OpenBSD to the metadata.json, in order to get the specs
covering it too.
Let me know if there is something wrong, or needs change/enhancement etc.