Context Navigation

Infrastructure

Timestamp:: Apr 20, 2013, 9:12:43 PM (12 years ago)
Author:: bonefish
Comment:: Update descriptions of packagefs - package daemon interaction

Legend:

: Unmodified
: Added
: Removed
: Modified

Obsolete/MovedToTree/PackageManagement/Infrastructure

-              v4
+              v5
  * The '''package kit''' is an API for package management related programming.
  * The '''dependency solver''' is a part of the package kit. It solves dependencies between packages.
  * The '''package management daemon''' is a background process that is activated whenever the user adds packages to or removes them from one of their activation locations. It verifies that all dependencies are fulfilled (prompting the user, if necessary) and performs whatever package pre-activation/post-deactivation tasks are required.
+ * The '''package management daemon''' is a background process that is activated whenever the user adds packages to or removes them from one of their activation locations. It verifies that all dependencies are fulfilled (prompting the user, if necessary) and performs whatever package pre-activation/post-deactivation tasks are required. The daemon is also contacted by the package manager (after it has resolved dependencies and downloaded all required packages) to do the package de-/activation.
  * The '''package manager''' provides the user interface for software installation, update, and removal. There are actually two programs, `pkgman`, a command line tool, and a GUI application.
 …
 Things are a bit more complicated due to the fact that packages usually have dependencies. E.g. when adding a package that has an unsatisfied dependency (e.g. needs a certain library that is not installed) it is not a good idea to activate the package nonetheless. The package contents (programs, libraries,...) might not work correctly, and, e.g. when shadowing other installed software, might even break things that worked before.
 The solution is that packagefs doesn't blindly act on its own when packages change, but first contacts the package management daemon. The daemon, a background process that sleeps most of the time, does then examine the new situation and checks whether all dependencies are fulfilled. If they are, it sends back an OK to packagefs which in turn activates/deactivates the packages as requested. In case there are issues with the dependencies, according to how it has been configured via settings, the daemon prompts the user immediately, checks remote repositories for solutions to the problem and presents the user with the possible options, or it even performs all necessary actions without bothering the user, if possible. One way or the other, in the end the problem has been solved or hasn't and the daemon reports back to packagefs with the result.
+The solution is that packagefs doesn't blindly act on its own when packages change. Instead the package management daemon, a background process that sleeps most of the time, examines the new situation and checks whether all dependencies are fulfilled. If they are, it tells packagefs to activate/deactivate the packages as requested. In case there are issues with the dependencies, according to how it has been configured via settings, the daemon prompts the user immediately, checks remote repositories for solutions to the problem and presents the user with the possible options, or it even performs all necessary actions without bothering the user, if possible. In the end, if the problems could be solved (e.g. by downloading additional packages), the respective packages will be de-/activated, or, otherwise, nothing will be changed.
 To avoid always having to check all dependencies when booting, packagefs caches the last consistent state of package activations in a file in the "packages" subdirectory. Unless something has changed, it can just activate the previously activated package. If something has changed, it has to contact the daemon as soon as possible.
+To avoid always having to check all dependencies when booting, the package daemon writes the last consistent state of package activations to the file "packages/administrative/activated-packages". When being mounted packagefs, reads that file and only activates the packages specified by it. If the file is missing or packages it refers to cannot be found or loaded, packagefs falls back to activating all packages in the "packages" directory. The package daemon, once started, checks the state.
 …
 While manual software installation is possible, the more comfortable way is to use the package manager. The package manager has a configurable list of remote software repositories. It knows what software is available in those repositories and what is installed locally. After the user has selected software packages to be installed/deinstalled, package dependencies are resolved, and packages are downloaded and moved to their installation location.
 The package manager has to synchronize its work with the package management daemon in order to avoid an inconsistent state when software is concurrently managed manually. This synchronization happens via the package kit, which communicates with the daemon.
+The package manager prepares a transaction directory, a subdirectory in the "packages/administrative" directory, which contains the new packages. It then contacts the package management daemon (via the package kit) to perform the package activation changes. The daemon moves the new packages to the "packages" directory, moves obsolete packages to an old state directory (also a subdirectory in the "packages/administrative" directory, with the current date and time encoded in its name) and asks packagefs to activate/deactivate the respective packages. The old state directories allow recovery of old states. That is particularly interesting for the system installation location. As as safe mode/recovery option, the boot loader offers the user to select an old installation state which can then be booted into, instead of the latest state.