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. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
