Brock Pytlik wrote: > The flow of control for the consumer of a PkgClient object is: > 1) Create an API object. This establishes which Image the API object is > associated with and assigns a progresstracker (for simplicity) > 2) Call either plan_install, plan_uninstall, plan_image_update > 3) Call prepare > 4) Call execute_plan > > Cancel essentially sends you back one step (so if it's doing 3 and > cancel is sent, the state will return to 2). > Reset returns the state to just after step 1.
When canceling or resetting, does that affect the image in any way? In other words, if a cancel occurs during the prepare phase, would that clear the download cache? > class PkgClient(object): > def __init__(self, img_path, version_id, progesstracker, > cancel_state_callable): > # Raises VersionException, NoImageException I still have reservations about a versioned API. > def plan_uninstall(self, pkg_list, recursive_removal): > # pkg_list: list of packages to remove > # recursive_removal: whether recursive removal should be > # applied > # Returns 1 if it has things to do, 0 for nothing to be done > # Raises imageplan.NonLeafPackageException, > # image.PlanCreationException Wouldn't image.UnmatchedFmriException be possible here too? > def describe(self): > # Returns None if no plan is ready yet, otherwise returns > # a PlanDescription describe_plan? > def prepare(self): > # Downloads the packages to disk. > # Prepares the indexes for updating. > # Raises search_errors.ProblematicPermissionsIndexException, > # UnknownPlanTypeException prepare_plan? > def refresh(self, full_refresh, auths=None): > # full_refresh: whether to do a full retrieval of the > catalog > # from the authority or only update the existing catalog > # auths: a list of authorities to refresh. Passing an empty > # list or using the default value means to refresh all > # known authorities refresh_catalogs or refresh_authoritiess for clarity? One request I have is that I need you to look at the review I posted for bug 1449 to see how you would tie the history object into this new API. I don't think you'd need to expose the history API through this -- just ensure that it gets called appropriately by these methods internally. Finally, I know you wanted the most critical actions to be part of the API, but I'd be interested in seeing *all* image-modifying operations be part of the initial API (e.g. rebuilding search indexes and changing authorities). Cheers, -- Shawn Walker _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
