> I was being too terse (short). I meant that if the catalog data you got > was shorter than you expected, I couldn't think of any reason you'd want > not to delete the temporary file, but maybe you could think of one.
Servicability might be a rationale for keeping the tempfiles around. It would be interesting to look at them should we need to debug an unexpected error. In general, though, I'm comfortable renaming the tempfile on top of the existing catalog file. There are fewer corner cases with this approach when a corner case is encountered. > I think it's more that your set has three objects in it, and they're > integers, so if you give it some other object, it will by definition not be > found in that set, so the next test will be false. Sorry. I have no excuse for why I was slow about getting my head around this. I've already had coffee. You're right, the test for "in retryable_socket_errors" necessarily implies that the members in the set are integers. I'll remove the redundant comparison. > > Adding another level of indentation to that code is going to make it > > even harder to read. The other retrieval methods don't perform a close > > at all and let the object be implicitly closed as it goes out of scope. > > Would you prefer that I do that instead? > > Okay, that's probably good enough. <sigh> Same for the manifest version. Okay, I'll change catalog. Manifest was already letting the garbage collector take care of this. Thanks again for the feedback. Do you want me to send out another webrev before I putback? -j _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
