On Thursday 06 March 2008, Philip Hands wrote: > For the retries, I'd have thought that that was related to > interactiveness, so we could perhaps check one of the existing ways of > indicating that you're trying to do a mostly non-interactive install, > and only do the retries if that's the case -- for the extreme case of a > fully automated install I'd much rather it takes ages and retries > several times, if it works, than see that a network outage broke the > install. Whereas, a normal newbie install should definitely whine about > a broken network as soon as it's noticed. Not sure about that. We generally try to avoid really different behavior for different types of installs (at least for different priorities) because to first thing you do when debugging issues is to lower the priority to gain more control. > Any suggestions on which flag(s) to check to decide the number of retries? If you're referring to your interactiveness suggestion, I'd think that debfonf/priority=critical is the only thing you could use. I'd propose to leave that until (much) later. Let's first just get a good basic framework implemented and tested.
Attachment:
signature.asc
Description: This is a digitally signed message part.