The `--noreplace` argument to `emerge` is generally coupled with
`--newuse` or `--changed-use`, and can be used instruct Portage to
rebuild a package only if necessary. Simply checking to see if the
package is already installed using `equery` is not sufficient to
determine if any changes would be made, so that step is skipped when
the `noreplace` module argument is specified. The module then falls back
to parsing the output from `emerge` to determine if anything changed. In
check mode, `emerge` is called with `--pretend`, so it produces
different output, and the parsing fails to correctly infer that a change
would be made.
This commit adds another regular expression to check when running in
check mode that matches the pretend output from `emerge`.
Signed-off-by: Dustin C. Hatch <dustin@hatch.name>
When running in check mode, the *portage* module always reports that no
changes were made, even if the requested packages do not exist on the
system. This is because it was erroneously expecting `emerge --pretend`
to produce the same output as `emerge` by itself would, and attempts to
parse it. This is not correct, for several reasons. Most specifically,
the string for which it is searching does not exist in the pretend
output. Additionally, `emerge --pretend` always prints the requested
packages, whether they are already installed or not; in the former case,
it shows them as reinstalls.
This commit adjusts the behavior to rely on `equery` alone when running
in check mode. If `equery` reports at least one package is not
installed, then nothing else is done: the system will definitely be
changed.
Signed-off-by: Dustin C. Hatch <dustin@hatch.name>
Due to a spurious newline we corrupted the payload. It depends on the order of the headers and if there were headers added by vSphere.
The Accept header was also not needed.
Starting point for a reference when doing pull request reviews.
If something doesn't meet the guidelines we can point people
at them. If something is bad but is not mentioned in the
guidelines, we should add it here.
The lxc container restart state does not ensure that the container
is in fact started unless another config or command is passed into
the task. to fix this the module simply needs to have the function
call added ``self._container_startup()`` after the container is
put into a stopped state.
Signed-off By: Kevin Carter <kevin.carter@rackspace.com>
Alan Loi
Andrew Udvare
Henrik Wallström
Dustin C. Hatch
Eike Frost
Brian Coca
Toshio Kuratomi
Anders Ingemann
Amir Moulavi
Rene Moser
Dag Wieers
whiter
Rob White
Robert Estelle
Will Thames
Siva Popuri
Gerrit Germis
Billy Kimble
Brian Brazil
Kevin Carter
Franck Nijhof
Greg DeKoenigsberg