User:DanielDrake/Yum

OLPC software releases are based on Fedora, which uses RPMs and the yum package manager as a cornerstrone of the project. However, in the OLPC case, yum drops out of OLPC's software vision as soon as the early stages of the software build process have run. This page attempts to explain:

• Why yum doesn't fit into OLPC's software vision
• Why yum doesn't fit into the OLPC deployment model as a system update tool, resulting in OLPC developing and maintaining its own update system
• Why individual users might face occasional problems with yum, even though it is a useful individual/developer tool and works fine most of the time
• The downsides of the current OLPC approach

Yum vs the build system

Yum is extensively used early in the software build system. We acquire packages from official Fedora yum repositories and yum repositories of OLPC's own packages, and then install them.

After yum has been used to install software packages within the under-construction software image root, our build system applies a whole series of modifications (some hacky, some clean) to the files that were installed by the packages. These modifications result from unique requirements of our software (our users and deployment environments differ greatly from the larger Fedora userbase). It would be preferable to have no modifications at all, and while our set of modifications is shrinking, this is a very difficult goal to achieve.

So, if you install a software image generated by the build system on your XO, and then use yum to update or install software, there is a good chance you are going to be overwriting some of the late modifications that were applied by the OLPC build system. Sometimes these modifications are only of minor importance (e.g. small optimizations, space saving techniques) but in other cases they are critical for the functionality of some part of the system.

So, while yum is a useful utility for developers and individual users to install some software of their choice or update existing packages, installing software through yum will occasionally cause loss of functionality. This is also one reason why Yum is not pushed to deployments.

Yum's inherent problems as a software updater

OLPC continues to focus on its goals to produce software which will scale massively. We're talking millions of laptops per country, many hundreds of laptops within small spaces. Our users are 6 through 12 years old. Environments are tough, electricity is unreliable. Connectivity is low, slow, high latency, and unreliable.

Perhaps the biggest showstopper for OLPC to adopt yum/RPM as a software update tool is the fact that it is inherently non-atomic. If you lose power in the middle of an update, you are likely to end up with problems. Sometimes these problems can be solved by Fedora's repair tools which try to replay RPM transactions, but sometimes they can't (or they need user intervention to fix, we can't ask this from a young child). Sometimes the problems are grave enough that you can't boot to run such repair tools.

Yum is inefficient when performing software updates. When the original decision was made not to use yum, yum would always download the full package contents on every update even if only 1% of the data had changed. In more recent times, yum uses delta's, but these only apply for certain packages on certain upgrade paths (see this article for some discussion).

Additionally, after installing a new RPM, the post-upgrade tasks are often very inefficient. For example, after updating a package which updated a plugin or something, entire caches are regenerated, including of the parts that did not change in the update.

Yum does not directly offer a mechanism to update from one Fedora release to another (it is possible, but heavily discouraged by Fedora developers). Instead, you must use a separate tool (Preupgrade/anaconda). When using preupgrade, deltas aren't used, you are forced to download the entirity of everything, even for packages which have barely changed from one release to the next. Anyone who has used preupgrade will know that it takes hours to complete, even on powerful machines, and you cannot use the system at all during the upgrade process. If you lose power during the final stage of the preupgrade process, you're in trouble (this once happened to me and after a couple of hours of trying to recover I gave up and did a fresh reinstall).

Yum can't remove software. You may have shipped some software that you now want removed, but yum doesn't directly offer functionality here.

Yum downloads databases consisting of every single package you could possibly install, even when there is just 1 update pending. It also downloads multiple databases, where much of the content of some databases (e.g. the Fedora release db) is deprecated by the contents of others (e.g. Fedora updates db).

For more depth, see the update mechanism for new releases discussion (June 2009).

olpc-update design and features

very efficient query system

linked into security

has the possibility of having 2 OS's installed.

Yum vs olpc-update

epoch

pristineness lost

pacakges get lost on update

Disadvantages

for non-sugar, no clear way of installing your own software

versions filesystem tree