> For example, if mirroring is a more restricted version of read-only, > then --mirror --refresh-index wouldn't make sense, nor would --mirror > --rebuild. There will be some examples of this just as soon as the bug > fix for 2693 gets pushed back. The idea is, if you know at start-up the > options passed don't make sense, error then rather than waiting a while, > and erroring when you don't have permissions to update the index (for > example).
Okay. I'll take a pass over this to see if I can put in some option checking. > I'd argue that eventually, we might not want an > InvalidContentException to be a show stopper and that instead we'd > remove the corrupted file and try again from a different mirror, but > perhaps not. We could do that; however, we'd want to permanantly remove the mirror from the list of mirrors under the assumption that the corruption was malicious. I'm not sure if we want to do that yet, though. > Fair enough, then how about something during start up with says in the > server log (once) "Starting as mirror, only x, y and z are supported > operations" or "a,b,c,d,e are not supported". I'm not sure I understand the rationale for this request. Are you concerned that admins/users won't be able to tell what methods the depot actually supports? If so, I've fixed the /versions/ method so it will correctly return the methods and versions that any depot supports. If a method isn't supported in a particular mode, and the depot is running in that mode, then the method won't be in the list of available methods. Does this address your concern? Thanks, -j _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
