Bug#422088: [Patch] wish preseed_fetch could distinguish between non-existance of a requested file and other failures to fetch file.

["Alex Owen" <r.alex.owen@gmail.com>]

On 06/05/07, Joey Hess <joeyh@debian.org> wrote:
> Alex Owen wrote:
> >               # TODO add progress bar
> > -             if wget -q "$url" -O "$file"; then
> > +             if wget -q "$url" -O "$file" 2>$log ; then
> > +                     rm -f $log
> >                       return 0
> > +             elif    grep "server returned error 404" $log >/dev/null ; then
>
> It's generally not a good idea to rely on command error messages like
> this.

I agree,
I was thinking that getting wget to give a sensible exit status rather
than parsing the error message. Perhaps that warrents a wishlist bug
on wget?

Perhaps reducing the grep line to:
> > +             elif    grep "404" $log >/dev/null ; then
would be more robust?


On 06/05/07, Joey Hess <joeyh@debian.org> wrote:
> An alternative way to do this is to first always load the standard preseed
> file, and then try to fetch the load preseed file, which if it exists, can
> override settings in the standard file.

I used to think that too... untill I discussed the idea with Philip Hands.


Alex Owen:
" I was thinking that a cleaner approach might be to have all public and
 all examples under classes then override that by placing stuff in
 local (or local_classes if you want to keep local for your way of
 doing things). I have test code which will test for the existance of
 [presee|subclasses|early_script|late_script] under local and use that
 and fall back to the equivilent file under classes if that fails."

Philip Hands:
" That sounds like the way I used to do that, but it has the problem that if
 you have a network outage, it's possible to have it skip an existing local
 file, and then carry on regardless, rather than having it complain that it
 failed to get a file it was expecting to exist -- this possibility, while
 slight makes the whole thing non-deterministic, so I'd rather avoid it
 (unless you have a scheme where a file that exists but is temporarily
 unavailable is distinguished from one that doesn't exist at all, in which
 case I'm all ears :-)

Alex Owen:
" If wget (busybox) gives different error code for "not found" response
 from web server as opposed to no response from server then you can
 distinguish."

I then wrote this patch as parsing the error message was easier than
hacking the wget code!

Thanks for your comments,
Alex Owen