Both will work. A subsequent call to yum will read the http_proxy environment variable and act on it, using the named proxy to obtain a network connection to the relevant repository. I have tested this successfully on Red Hat 5.7.

Yum Failures

Older versions of Red Hat 5 are more fussy. RHEL 5.4 will allow the first form above (export http_proxy=http://192.168.1.100:8080), but use the second form and yum will barf extravagantly, leaving you with a lengthy Python trace back.

The difference seems to lurk in the standard Python module “liburl2.py”. In newer releases, this module is equipped with a block of code called _parse_proxy that comprehends the second form of the variable above (export http_proxy=192.168.1.100:8080) and properly parses it. The _parse_proxy function is missing on older releases.

This difference is not reflected in the yum or Python version numbers, or in the library’s “__version__” string. Two machines can have the same version number of yum, Python and the module, and yet react differently to the http_proxy environment variable. The only way to check your installation, it seems, is to grep the file:
# grep _parse_proxy /usr/lib64/python2.4/urllib2.py

will return nothing if you have the old version, and about 10 lines if you have the new (fixed) version.

The later library, capable of processing both formats, is part of package python-libs-2.4.3-44.el5 on RHEL 5.7. The older version was delivered in the main python package, eg python-2.4.3-27.el5 on RHEL 5.4. I am not sure exactly when the library was fixed, or when it switched packages, but the difference can be confusing on older machines.

It begs the question of why the authors did not increment the library version number, or at least insert some helpful comments. I am not a Python expert. If you can shed any more light on this, please leave a comment.