Re: Patch to tidy up wget use, and add return=4 when 404's are seen
On Mon, Feb 18, 2008 at 04:58:24PM +0100, Frans Pop wrote:
> On Saturday 16 February 2008, Philip Hands wrote:
> > I've tested this briefly, and it seems to work OK, but failed
> > with a grub error (that I notice has been mentioned by other, so
> > I'm currently assuming that's not related to this patch)
> >
> > First I've made preseed_fetch callable as fetch_url, so that it can
> > be used outside preseeding without treading on the contents of
> > /var/run/preseed.last_location
>
> I've quickly read through the patch and there's one thing I really dislike:
> the added dependency of net-retriever on preseed-common.
>
> I suggest to add either a script or a function library to di-utils that
> performs either the "wget_plus" or the "fetch_url" functionality. I'm not
> sure which of those 2x2 options would be the most logical.
Putting fetch_url into di-utils was what occurred to me initially -- the only reason for the way I did this was because preseed_fetch and fetch_url are currently the same script.
If we put fetch_url into di-utils (a good idea IMO) then I'll implement
preseed_fetch as something that calls fetch_url having done the
last_location magic to get the URL to be fetched, which will also make
the code clearer
> I also wonder how this changes the logging (in syslog). If it still visible
> what the result of a wget was?
Erm, no -- the grep eats wget's STDERR.
It'll probably need a tmpfile to store the wget output (or the existence
of tee, which I believe is currently absent from d-i and the use of some
odd file-handle hacks to preserve that)
I'll look into it.
> A more descriptive name for wget_plus would be nice too...
Yeah, I was being less than inventive there -- I imagine a better name
will emerge when a better version appears.
The thing that still worries me about this is the existing state of the
net-retriever fetch() code, with its apparently spurious while loop -- I
note that according to svn blame that's one of Joey's, but I'm guessing
that it's been chopped about a bit to end up like that, and so has lost
it's way somewhat. It's a little difficult to re-implement without
being certain of the original intent.
> Cheers,
> FJP
Cheers, Phil.
Reply to: