I did some review to my micro portsnap patch, thanks also to the suggestion on the FreeBSD forums and -stable mailing list.
In particular, as someone pointed out, using wget(1) is not a good idea because it is not part of the base system and requires an admin to manually install it from ports or packages. That is not a big deal in my opinion, and it is the reason why I made a change so that it was possible to configure, using /etc/portsnap.conf, a way to specify that wget(1) was required. To make it even clearer, I also created a function check_downloader that is used to check the presence of the program executable used to download stuff (either phttpget or wget).
I was not fully happy with such patch, but I have not a better idea until someone on the -stable mailing list pointed out that FreeBSD (of course!) has already a downloader: fetch(1).
The problem with fetch(1) is that it requires a full URL while portsnap was internally dealing with clean server names.
So I reverted the patch in order to avoid using wget(1) and to use fetch(1) by means of a flag in /etc/portsnap.conf and introduced a new variable in the internal portsnap implementation, SERVER_PROTOCOL, that simply handles "http" in the case of the usage of fetch(1).
The patch has moved into another path within my repository and is available here.
3 commenti:
Nice work. Thanks. Have You patched freebsd-update command which has the same issue when used with proxy and auth ;-) ?
@rop: freebsd-update works for me with the http_proxy variable out of the box. At least on 9.1-RELEASE, that is the only version I'm currently running behind a proxy now.
Well.. I'm on 9.1-RELEASE too but the problem still exist. Searching with google I've found this http://www.freebsd.org/cgi/query-pr.cgi?pr=153211 which seems to describe my problem. Unfortunately I have no idea how to get those files that should be placed in /var/db/freebsd-update/files folder which is empty now (fresh box).
Posta un commento