On Mon, May 28, 2012 at 3:49 PM, Daniel Baumann
<daniel.baum...@progress-technologies.net> wrote:
> On 05/28/2012 03:47 PM, Rui Miguel P. Bernardo wrote:
>> proxy is used in chroot;
>
> for every Chroot(); call, the environment inside the chroot is cleared
> and stuff like http_proxy gets set. once Chroot(); terminates, the
> 'chroot environment' is not existing anymore.
>
>> why using proxy in debootstrap taints anything?
>
> debootstrap is called withing the host systems context, not the target
> system.
>
> tainting here means that your host environment is changed once an lb
> call terminates.
That's why I've put these lines in lb_bootstrap_debootstrap
+ export http_proxy="${PREVIOUS_PROXY_ENV}"
+ [ "$PREVIOUS_PROXY_ENV" = "" ] && unset http_proxy
I can see now that, most probably, this is only correct if someone
uses apt-cacher AND http_proxy, kind of strange to me but it can be
someone environment. If someone only uses apt-cacher, like me, this
restores http_proxy to unset. In my case (apt-cacher only) my patch
works and debootstrap doesn't fail nor does chroot download, so I
think this patch doesn't taint anything. I'm just not sure what
happens if no apt-cacher is installed and http_proxy is set and
working.
my original doubt with this "unset http" is that I'm not sure if an
"export VAR" in called script (lb_bootstrap_debootstrap) will be
exported to the script that called it (lb build). I think not, but
I've added those lines to be sure. My doubt was that it just may be
useless to unset it because it's not exported anywhere else, if my
assumption was correct.
Also, just like in lb_binary_debian-installer, http_proxy should not
be set elsewhere than where it downloads packages because it also
downloads other files that apt-cacher doesn't support, so better to
unset it after its use than having a http_proxy set and later down in
the script cause some download failure.
If doing this this way is the wrong approach (although it works and is
simple) what would be the correct way? Some guidance on what can be
done and what should be done will be appreciated.
Maybe a new var should be created, like LB_BOOTSTRAP_PROXY, that would
default to LB_APT_HTTP_PROXY value and add it to config/bootstrap.
Then make lb_bootstrap_debootstrap use LB_BOOTSTRAP_PROXY in
debootstrap command instead of LB_APT_HTTP_PROXY to not mix
config/chroot and config/bootstrap? This would require much more
changes (creating new var and lb option, etc) because of the 2nd part
of the patch (udeb downloads in lb_binary_debian-installer, requiring
another var and option).
--
To UNSUBSCRIBE, email to debian-live-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/cap1yx5xy7y8oaioxndo6zmtwgozvi-rf98rrbmj6dt5er_e...@mail.gmail.com
