- removed previous 'typification' of input as it needs it is typed by
module as strings and needs to be output as strings, making it
useless.
- now checks for vtype and value against None when question is specified
- simplified set_selections as vtype and value should have a string
value going in.
- added example of querying questions for a package
- added module requirement of question,vtype and value being required
together.
- field names are more consistent with debconf
- values are now 'booleanized' or accepted as list/set objects when
pertinent
- updated docs to reflect all of the above and debconf cli tools
required
While we're on it, change $pkgdesc to follow its counterpart from
official repositories. Additionally don't install RELEASES.txt and
CONTRIBUTING.md; there is little use for them from the user's perspective.
Refining the fix made in #5885.
Merging this quickly after PR as further testing of of earlier fix demonstrated flaws. Those flaws are now removed and tested to be removed.
It turns out that some of the assumptions in #5885 were slightly off. The previous fix relied on a call to the module to creat a tmp_path. This is insufficent as there are few cases that we need to have the tmp directory before we make the module call. If we don't have a tmp_path before we do a recursive call or when we find a file that does not match the remote md5 hash we need to create a tmp directory. Also we are not more percise when we will need to clean up the remote tmp_path.
There is a subtle bug in how the git module currently works. If the
version you request is a tag name, and you've already got the repo
cloned, and the tag name is a new tag, but refers to the already checked
out working copy, the git module would exit early without change. This
is bad as it means the new tag ref was not fetched and could not be used
in later tasks.
This change will check if the version is a remote tag, and if the tag
doesn't exist locally. If that is true, it'll do a fetch.
The activity could still be seen as not a change, because the working
copy won't be updated, if the new tag refers to the already checked out
copy, but that's not different than before and can be fixed as a more
comprehensive overhaul of tracking change in the git module.
A fix for uri module regarding following redirects. The old behavior would follow redirects either way. This change clarifies the functionality and makes it a bit more explicit. Comparing the old behavior to the new 'yes' == 'all', 'no' == 'safe' and now 'no' will not follow any redirects. Historic behavior is still supported and documented with a push to the new values.
