On Wed, Jul 29, 2009 at 09:10:02PM -0500, Shawn Walker wrote: > Edward Pilatowicz wrote: >> On Tue, Jul 28, 2009 at 04:35:31PM -0500, Shawn Walker wrote: >>> ... a warning will be provided to the client that there >>> may be something wrong with the repository (packages may be >>> missing, etc.). >>> >> >> there are multiple conditions where you propose to alert the client that >> there may be something wrong with the repo. i don't think that this is >> all that helpfull of an error message. > > There are really only two options: abort or continue. We've run into > problems on multiple (but thankfully rare) occasions where repository > changes caused a client failure, so the consensus so far has been to > attempt to correct the situation, warn the user, and continue. > > Remember that these cases should be the exception, and not the rule. The > general idea is to suggest that the user contact the repository > maintainer for assistance. >
yes. but these conditions will happen. and when one of these instances happens the user probably won't contact the repo maintainer because the command emitted a warning but it continued on. and then even if they do contact the repo admin, the admin will ask them how the error was trigger and if it's reproducible. which it won't be. and who knows if the client will work correctly or not? what will be the failure modes and how are people supposed to diagnose the subsequent random failures? the repo admin will never realize that some tweaks that they made resulted in busted clients... >> it seems to me that in this case instead of warning the client user that >> the repo could be broken, it'd be best if we simply tell the client user >> that the repo has been rebuilt. > > We don't know if the repository has been rebuilt. It could have been > rebuilt, or it could be somehow broken and not sending correct > responses, or it could have been restored to an earlier version that > doesn't contain packages they're currently using. > and in any of the possible cases that you site above would you really want the client to continue to access that repo? (say i'm running b118, would i really want to refresh my catalogs to a repo that only has b117?) >> then, before just downloading the newest repo catalog the client could >> to scan it's existing catalog/pkg info and compare it to what's >> available in the rebuilt repo. if nothing has changed for installed >> packages then there is no problem and the client can download the latest >> catalogs and continue the current operation. > > For incremental updates, we purposefully avoid downloading the catalog > 'parts', so that won't work. Remember also that catalogs will be signed > in the near future, so there is the cryptographic integrity to consider > as well. We also have no way of knowing if a repository was 'rebuilt' > vs. some other event. > but the client has all the manifest data for packages it has installed right? why can't we verify this data against the repo. imho, it's ok if this check is an expensive operation. as you mention earlier, it should rarely happen. >> but if metadata has changed for packages that are already installed, >> then the *client* is actually broken wrt the current repo, and we should >> tell the user that. we could also tell them specifically which packages >> are broken and refuse to update the local catalogs until the issue is >> resolved (perhaps by having the user uninstall the broken packages, or >> by contacting their repo admin to tell them that they've broken package >> foobar, etc). > > The consensus so far has been to warn the user, correct if possible, and > drive on. Currently we tend to just 'throw up our hands' and fail > instead of attempting to continue. > i'm not sure that driving on is the right thing. if a repo admin has done something and accidently screwed up a repo, should clients drive on and propegate the brokeness? i would think not. > Also, it's intentional that packages might be removed from the catalog, > and so we can't assume that because a package or metadata is missing > from it that the package is broken (think toxic packages removed for > legal reasons, etc.). In short, the system is designed and intended to > allow for packages that are marked as being from a specific publisher, > but are not in any catalog. > i'm not that concerned about the case of a package disapearing from a repo. that scenario (in my mind) would be more of a warning than an error. (there'd be no pkg metadata that would be out of sync.) but at the same time i'd want to know that the repo has stopped serving up the packages i'm interested in. the case i'm more concerned about is if some package data has changed for packages that are already installed. in that case the client is broken wrt the server. if you don't want to call it broken then fine, call it inconsistent. in either case charging ahead seems like a bad idea because who knows if the resultant combination of bits is going to work or not. in this case we should alert the user, abort our operation, and optionally provide them with a '-f' flag to let them ignore the errors without resolving them in any way. > I'm in the process of adding a section to each file to account for > digest and cryptographic data which should further address verification > issues. > > Thanks for the feedback, > -- > Shawn Walker _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
