Difference between revisions of "Repository Server"

Revision as of 14:47, 15 June 2009

The Respository Server is where the Eiffel Library Repository holds and manages different versions of Eiffel library packages. Packages can be uploaded, download and updated using a client tool set.

A Better Server

There is one area where package repositories do not work well and it can be very frustrating - broken packages! It happens from time to time and when it does it feels like the end of the world, well for some people. For anyone who has used MacPorts or apt in Ubuntu a misbehaving package can be a brick wall to progress. Matters are made worse when you are a supplier of a package with a broken dependency. Not only does the dependency package not compile but the author's package wont either. The number of broken packages as a result of a single broken package can be exponential. Eiffel packages contain source libraries and will be susceptible to such breaks, so whatever can be done to prevent breaking changes from entering the repository the better for it.

The single, external entry point to a broken packages is via an uploaded packages. There is another course to cause once stable packages to become broken, but this is through age - packages can become stale when not maintained. Both these issues can be resolved with active monitoring of uploaded package, triggering a series of events to ensure the integrity of a packages and those that depend on it.

= Stable Repository

The server uses the notion of a "stable" repository. This refers to the packages made available for all end-users to download and other packages to depend on. Stable packages have been checked for integrity and should not cause problems when downloaded onto an end-user's system.

Holding Area

When a packages is uploaded to the repository the library will not actually be committed to the stable repository. A holding area serves to check the integrity of a packages before making it available to the general public as an upgrade to an existing packages or a new packages. Integrity is checked through a chain of compilation checks which must all pass or achieve an acceptable pass mark to be treated as a stable package to integrate.

Packages uploaded are placed in an queue, called the Integrity Holding Queue, to await a slot for processing the integrity checks on the applicable platforms.

For more information on these checks, see Integrity Checks.

Avoiding Multiple Entries in the Holding Queue

Utilizing a holding area and a queue of packages to be checked may cause a minor back log and lead to a situation where a package is uploaded once, the authors realize there is a mistake and then repackage the package and upload it again. In such an event the server should halt any checks being performed on the old version of the package, or remove any older version from the holding queue, and then place the newly uploaded package at the back of the queue. No communication will be sent to the package's maintain regarding older versions of the the upload package in the holding queue.

Self Referential Breaks

Maintaining a holding queue can lead to form or race condition where a package, early on in the queue, is uploaded and then later another package depending on that earlier package is uploaded. The earlier package introduces changes which will break the code of the later package, which were not detected because the new version (of the earlier package) is not yet available to check against. When it comes time to check the integrity of the latter package it will fail.

This situation is consider to be rare and not needing to be addressed immediately. Even in the even of this happening, the latter package will be rejected and the maintainer informed of the rejection. The rejection notification email should contain recommendations to synchronize with the stable repository and try again.

Removing Libraries

When a package is request for removal from the repository it is not actually removed completely. To remove the package would prevent other packages from compiling successfully. Instead the package will be marked as obsolete and all packages depending on the package will be notified of the new package status. Those same dependents will also be modified to use a maximum version number of the obsolete package. It is hoped all package maintainers respond and update their package, and upload a corrected version. Once the number of dependents falls to zero the package can actually be removed from the repository.

It will be recommended for a maintainer to explain why they are removing the package and hint at another package to use in place, for the assistance to those authors of packages using the removed library.

Maintainers of packages marked obsolete will not recieve any status notification emails regarding any packages breaking the obsolete package, because the package is considered no longer maintained.