Platform Team/packagekit-backend-presolve

From Sugar Labs
Jump to navigation Jump to search

Summary

This is a PackageKit backend which is intended to be used on restricted systems like XO-1 laptops where regular package management routines are too heavy for limited amount of memory or CPU resources.

The reason

The known, for the author of these lines, current practice is:

Both ways are useful for usecases they were created for. But there is a situation when they both become less useful. Having Activity Library (or its distributed version on regional or school server), XO users might download activities directly from the Internet (or distributed server). So, it is becoming hard to use:

  • olpc-update,
    Activity Library might have non-standard dependencies and it is either hard to keep olpc-update server up-to-date, or, useless to install all possible dependencies on every XO.
  • sugar-client,
    activity dependencies are, in most cases, from official repositories when sugar-client's 3rd party repository are useless.

In other words, there is a need to install particular packages from official Fedora repository and using existing methods is either impractical (olpc-update) or impossible (sugar-client). Fallback to using regular (like yum) ways is also not useful because they take too much memory (at the first) and CPU resources, it is a special problem on XO-1 laptops.

The packagekit-backend-presolve is intended to solve this issue by providing standard way (it is PackageKit backend, i.e., sugar launching code will be common for all platforms, it will call PackageKit all time) to install activity dependencies and consuming as less as possible resources on XO laptops. The backend was designed to support reliable launch from resources like Activity Library and/or Sugar Network when there are activities that might have non-standard dependencies. This backend might be treated as a temporal solution, i.e., when either XO will be powerful enough or regular installation procedures will take less resources, it will be possible to switch to default PackageKit backend (without making changes in activity launching code).

Concept

The general idea is exactly about presolving dependencies tree for limited list of top-level packages and store this information on a server. Clients need to download only small amount of information (in comparing 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 all presolved dependency trees don't include packages from some standard installation. In other words, particular dependency tree doesn't end with the glibc packages, instead, it ends with sugar package. That should drastically restrict the length of trees.

Finally, missed packages will be installed directly by using rpm -i command.

Upside

  • Users need to download metadata on package basis on demand and avoid downloading 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 rpm -i command;
  • Activities launching code will be general, i.e., will work as-is on all platform that have PackageKit (literally, on all mainstream GNU/Linux distributions), not only on XO laptops with packagekit-backend-presolve installed.

Downside

  • The project is intended to install only limited number of top-level packages, i.e., packages that have presolved dependency trees on a server; for example, it is not capable for full system update;
  • Support dependency trees on server side.

Implementation

Premisses

The implementation is following the premisses:

  • Being targeted only to XO laptops (assuming that other platforms are more powerful where standard PackageKit backend can be used);
  • Keep less work on XO side and more work on server side to make installation process on client side as fast and reliable as possible;
  • Implement only first-needed functionality and provide more complex features as required, e.g., current implementation doesn't support updating already installed packages leave it to hard (and rare, e.g., yearly based) full system updates (re-flashes or calling olpc-update) and incremental regular updates (sugar-client).

Overview

  • The client side keep the list of installed, via backend, packages;
  • After getting install request, it will check if requested package is already installed;
  • If not, download a file from know HTTP location with the requested package's name;
  • Downloaded file contains RPM url for requested packages and a list of package-name/url pairs for all dependencies (starting from some known point);
  • All missed RPMs will be downloaded and installed by directly calling rpm -i;
  • Install packages list will be updated correspondingly.

Sources

Clone source repository from Gitorious project: 

git clone git://git.sugarlabs.org/desktop/packagekit-backend-presolve.git

Getting involved

  • Subscribe to the sugar-devel mailing list and email with the subject prefixed with [PLATFORM].
  • Ask your question on IRC channels, #sugar (not logged) or #sugar-newbies (logged).
Retrieved from "https://wiki.sugarlabs.org/index.php?title=Platform_Team/packagekit-backend-presolve&oldid=83007"