[email protected] wrote:
I'm fine with implicit refresh not failing, but in that case we ought to remove the --no-refresh option from install entirely. There's no point to having it exist if we're going to suppress failures that occur during an implicit refresh -- there's no explicit refresh option to install.
I'd be fine with that, personally. Although that will require several change to the test suite that rely on --no-refresh for testing.
My concern with the transport is twofold. First, I don't want to get in the habit of running the captive portal test more than once. Secondly,
I agree.
I was under the impression that the transport's callers would prefer not to disclose a lot of information about their underlying reasons for calling. However, if you're less concerned about this second point, and don't have a problem with refreshes knowing whether they're implicit or not, we could pass a flag to get_catalog that indicates whether the portal test should be run or not. Since 9929 makes the call occur in the transport method, instead of hiding it within the initialization routine, it's a bit more obvious what's going on.
I think the way to handle it is to let the caller deal with the behaviour. That is, I expect the client to catch general network failure exceptions when they do an implicit refresh and then ignore them if they don't care. In other words, I don't expect the transport engine to deal with this.
In that case, will that still avoid the multiple portal test errors?
This aspect of the design didn't pertain directly to the changes in 9929, and they were rather urgently needed by AI, which is part of the reason why I was impatient to get this fix checked in. (I was hungry, too. *rar*). In any case, I apologize for the tone in the previous e-mail.
No worries, I never took offence by it. Cheers, -- Shawn Walker _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
