Comment 12 for bug 466142

I was able to demonstrate that all of [apt-get, dpkg, aptitude, gdebi, gdebi-gtk, synaptic] _do_ allow the $http_proxy environment variable to propagate down to the package's install script, and therefore to `wget`:

   cd /var/cache/apt/archives
   rm -f flashplugin-installer*
   apt-get install flashplugin-installer # to cache it
   RMV(){ apt-get remove flashplugin-installer; }
   RMV; http_proxy=fail:// apt-get install flashplugin-installer
   RMV; http_proxy=fail:// dpkg -i flashplugin-installer*.deb
   RMV; http_proxy=fail:// aptitude reinstall flashplugin-installer
   RMV; http_proxy=fail:// gdebi flashplugin-installer*.deb
   RMV; http_proxy=fail:// gdebi-gtk flashplugin-installer*.deb
   RMV; http_proxy=fail:// synaptic& # then install flashplugin-installer

These of course all fail with a `wget` error message about wrong schema for the proxy URL; clearly demonstrating that $http_proxy got to them.

Whereas this one:

   RMV; http_proxy=fail:// software-center&

passes _no_ proxy setting to the install script -- which then proceeds to try a fruitless direct connect.

So the actual current situation is that this problem is _fixed_ for the other installers, at least the ones I tried, while software-center recreates the problem for itself by purging $http_proxy from the environment of its subprocess; or, in any case, failing to get it across to `aptd`.

The same behaviors apply with respect to synaptic & software-center when loaded from my window manager menus. $http_proxy is set by something and propagates down as it should, except in software-center.

I did not test update-manager, not knowing how to trick it into thinking a back-rev version of flashplugin-installer was on my system needing an update.

(There's another whole set of bugs with this: my GUI-configured proxy setting is supposed to be the same for all protocols, but only $http_proxy is getting into my env, and `wget`, at least, interprets this literally as proxying only HTTP.)