Yum Time Machine aka Predicted Package Transactions Computing dependencies between packages takes up much of the time when a user asks a dependency solving package manager such as yum to install, update, remove or otherwise decide what to do to a package on a system. Current systems of computing dependencies performs the action when the user requests that the package manager makes a change to what packages are installed on the system. The method documented here is a means to perform those computations before the user requests them and thus save time when the user actually makes the request. A package manager can record a log of the actions that a user normally performs with the package manager. In yum, the yum history database feature performs this function. This feature was created to allow users to determine what actions were taken in the past and allow yum to sometimes perform actions related to those past actions (for instance, rolling back a previous transaction.) Predicted Package Transactions utilize this logging feature to analyze what actions the user has taken in the past. The actions that the user performs on a regular, ongoing basis, are then candidates for precomputing the results of before the user requests it. The package manager may optionally analyze these actions for the times when the user normally requests them and the time that it takes to perform them is estimated or the package manager may be set to perform the next steps at a set time every day. At a point in time before the user next performs the predicted action, the package manager downloads the metadata associated with the package repositories that the user normally uses. This step ensures that the information used to perform dependency calculations is reasonably current. The package manager then calculates the results of the user running the action. This step generates data which, at minimum, includes information about the present state of the packages installed on the system, each package that the package manager will need to act upon to complete the transaction including the package's checksum, name, the repository that it comes from, and the versions of all the repositories involved in this transaction. This data is then saved persistently and keyed so that the package manager can find the information based upon the user action that it is used for. When the user runs the predicted action, the package manager checks whether it has a saved transaction state for that action from the previous step. If it does, the package manager loads the information and checks whether the information is out of date or not. To do this, the package manager first checks whether the state of packages on the system has changed since the predicted transaction was saved. If it has the package manager must fallback to performing the action as it normally would, otherwise it proceeds to the next check. It next checks whether any of the repositories that the packages are coming from have changed state. If not, the package manager is able to proceed to the next step immediately. If so, the package manager must retrieve the information about the packages that are present in the transaction that are in the repository. The package manager then checks the package checksums against the information retrieved from the repository. If any of the packages have non-matching checksums, the package manager must discard the predicted transaction and perform the action as it normally would. Otherwise, the package manager can continue to the next step. The package manager will next use the saved information to complete the requested action. How it does this depends on how the dep solver chose to save the information in the first place but it can include reloading a state machine with state saved persistently, loading the list of packages into the depsolving mechanism and letting the dep solver perform the final depsolving step again, or passing the package list onto the next phase of package management which performs the requested actions against the packages installed on the system. Notes: A further refinement of this could take into account changes to the packageset that span repositories. This refinement would have a tradeoff. The method described here allows us to precompute transactions and tell if the transaction should be discarded later because it is no longer possible to complete it with the packages available in the repositories. It does not tell us if a newer package exists in another repository that running the transaction from scratch would pick up now. Changing the algorithm to check for newer packages in any repository would have the following effects: * Slower as we'd have to check all of the repositories that have changed since the precomputed run for a package that is newer than the one in the precomputed transaction instead of only the repoitory/package combinations that were selected in the first run. * More likely to discard the precomputed transaction as there is a larger pool of potentially changed packages.