Platform Team/packagekit-backend-presolve: Difference between revisions
No edit summary |
|||
| Line 22: | Line 22: | ||
== Concept == | == Concept == | ||
The general idea is | The general idea is to pre-resolve dependencies for a limited set of top-level packages and store this information on a server. Clients need to download only small amount of information (compared with entire list of available packages) to reuse it as-is (and avoid reading database into memory during solving process). | ||
Another important point is that | Another important point is that pre-resolved dependency graphs don't include packages from the base system. In other words, a particular dependency tree doesn't end with the {{Code|glibc}} package. Instead, it ends with the {{Code|sugar}} package. This expedient should drastically reduce the size of trees. | ||
Finally, | Finally, missing packages will be installed directly by using the {{Code|rpm -i}} command. | ||
=== | === Upsides === | ||
* Users | * Users download metadata on a package by package basis, thus avoiding the need to download the full packages database; | ||
* After downloading, metadata will be reused as-is, i.e., after checking what packages were already installed, system will download only missed RPMs and install them directly by calling {{Code|rpm -i}} command; | * After downloading, metadata will be reused as-is, i.e., after checking what packages were already installed, system will download only missed RPMs and install them directly by calling {{Code|rpm -i}} command; | ||
* | * Packaged activities will be distro-agnostic. That is, they will work unmodified on all platforms that provide PackageKit (which means all mainstream GNU/Linux distributions). | ||
=== | === Downsides === | ||
* The project is intended to install only limited number of top-level packages, i.e., packages that have | * The project is intended to install only limited number of top-level packages, i.e., packages that have pre-resolved dependency trees on a server; for example, it is not capable for full system update; | ||
* | * Need to support server-side generation of dependency trees. | ||
== Implementation == | == Implementation == | ||
| Line 43: | Line 43: | ||
=== Premisses === | === Premisses === | ||
The implementation is following the | The implementation is following the premises: | ||
* Being targeted only to XO laptops (assuming that other platforms are more powerful where standard PackageKit backend can be used); | * Being targeted only to XO laptops (assuming that other platforms are more powerful where standard PackageKit backend can be used); | ||
| Line 51: | Line 51: | ||
=== Overview === | === Overview === | ||
* | * Clients keep a list of packages installed by the back-end; | ||
* After getting install request, | * After getting install request, the back-end will check if the requested package is already installed; | ||
* If not, | * If not, it downloads a file from know HTTP location with the requested package's name; | ||
* Downloaded file contains RPM url for requested package and a list of package-name/url pairs for all dependencies (starting from some known point); | * Downloaded file contains RPM url for requested package and a list of package-name/url pairs for all dependencies (starting from some known point); | ||
* All | * All missing packages will be downloaded and installed by directly calling {{Code|rpm -i}}; | ||
* Installed packages list will be updated correspondingly. | * Installed packages list will be updated correspondingly. | ||