Comment 1 for bug 557443

Hello, the following information should complete this bug as a valid SRU report, to hopefully upload this fix to Lucid.

Further discussion of the problem:

The command used to invoke the backend will be of the form:

kdesudo -- PATH=/usr/share/checkbox/scripts:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games /usr/share/checkbox/backend

kdesudo absolutely can't handle the environment variable so if this command is invoked by hand, it simply exits without invoking the backend.

When this happens, the frontend just hangs there, waiting for the backend to start and respond to control messages. This obviously never happens and the frontend will stall forever.

Solution:

Checkbox revision 787 works around this problem by adding a --path parameter on the superprivileged backend. The backend then adds the given path to its own environment, in substitution of passing the PATH environment variable which kdesudo can't handle.

The backend_info plugin takes its own $PATH and passes it, via --path, to the backend when spawning it. This way, even under kdesudo, we ensure that the backend will have the correct path, all while avoiding confusing kdesudo with the PATH variable before the command to execute.

TEST CASE:

1- Boot a Kubuntu 10.04 LiveCD choosing "Try Kubuntu without installing"
2- Open konsole and install checkbox:
   sudo apt-get update; sudo apt-get install checkbox-gtk
3- Launch checkbox-gtk from the terminal
4- When it gets to the "Gathering information from your system" it stays there forever, as the frontend is waiting for the backend to start and open the communication pipes (which never happens as the backend fails to start).
5- Additional verification is to ps wwuxa |grep backend and confirm that the backend process is not present.

Regression potential:
The new code is just passing the contents of $PATH (which coming from the environment should already be properly formatted) to the backend (handling it through Python's options module so it should also be quite resilient). Thus the new code doesn't look like it could introduce potential problems; An empty $PATH would result in a lot of failed tests (as the backend might fail to find commands to run) and a malformed $PATH would have given problems with the old version as well. Given that the original behavior was "doesn't work at all", chances for a regression are almost nil.