- Manifest format parsing is now checked by the file extension ie: .json, .yml or .yaml.
- load_yaml in common/tools is the same as the json version.
- schema checking of manifest still passes (and fails appropriately) like the json manifests.
- I've also included a sample yaml config based off of the debian test json manifest.
I've added a _Contributing_ section to the README and a [CONTRIBUTING
file](https://github.com/blog/1184-contributing-guidelines). I do not
expected for these changes to be merged right away, as they can be seen
as a draft from what I've observed in the past weeks. The intention here
is not only help the developers that are new to the project, but also
make it easier for Anders to deal with new patches.
Three of the last developed plugins remained on the old `plugins/`
folder. This probably happened because they didn't existed when the
`documentation` branch were created, so they weren't moved when it was
rebased against `master`.
Add two comments to the InstallGuestAdditions, explaining why its return
code will not be checked with `log_check_call()` or even manually
grabbing the status informed by `log_call()` itself.
Previously discussed on the #55 issue and 43e3d96 commit.
I've been discussing that with Anders for over a week and we agreed that
checking the return code of the Guest Additions installation is just a
waste of time. It seems to return 1 no matter what happen, like:
- It has been launched without administrator privileges: OK
- Requirements like bzip2 and gcc are missing: OK
- Kernel headers or dkms are missing: OK
- It was installed successfully, but without X11 drivers: ???
There isn't even a way (at least until the current 4.3.x version) to
disable the X11 drivers installation. The `--nox11` option, just "Do not
spawn an xterm".
And the worst part: until the version 4.2.x, it returned 0 if it could
be installed with no errors beside this one about the missing X11
drivers. This means that this verification will most likely fail on any
other version older than 4.3.x, preventing the build from finishing in a
successful way. So, we can't really rely on its return code whatsoever.
That said, neither him or me likes the idea of ignoring the return code
of a command. It just happens that we can't do anything about that.
