[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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,

Cheers, Phil.

Reply to: