Repository Server - Revision history

Manus: /* = Stable Repository */

2009-06-16T15:31:50Z

‎= Stable Repository

Paulb at 23:47, 15 June 2009

2009-06-15T23:47:57Z

Paulb: /* A Better Server */

2009-06-15T23:32:53Z

‎A Better Server

Paulb at 23:32, 15 June 2009

2009-06-15T23:32:05Z

Paulb: Initial page

2009-06-15T22:33:09Z

Initial page

New page

{{UnderConstruction}}
[[Category:Eiffel Library Repository]]

The server is where the library repository holds and manages different versions of Eiffel library [[Repository Packages|packages]]. The repository is where packages are downloaded from and are considered "stable" to use by all. This part of the repository is to be known as the stable repository. There will be no library packages stored or uploaded directly to this stable repository in order to prevent one of the major crutches in a library package manager.

== A Better Server ==

There is one area where package repositories do not work well and it can be very frustrating - [http://www.google.com/search?q=broken+package 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 [http://www.macports.org MacPorts] or ''apt'' in [http://www.ubuntu.org 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 [[Repository Packages|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.

=== 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 Checks|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.

@@ Line 10: / Line 10: @@
 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 ==
+=== 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.

← Older revision		Revision as of 23:32, 15 June 2009
Line 9:		Line 9:

	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.		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.
		+
		+	== Uploading Packages ==

	=== Holding Area ===		=== Holding Area ===

← Older revision		Revision as of 23:32, 15 June 2009
Line 27:		Line 27:

	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.		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.

@@ Line 2: / Line 2: @@
 [[Category:Eiffel Library Repository]]
-The server is where the library repository holds and manages different versions of Eiffel library [[Repository Packages|packages]]. The repository is where packages are downloaded from and are considered "stable" to use by all. This part of the repository is to be known as the stable repository. There will be no library packages stored or uploaded directly to this stable repository in order to prevent one of the major crutches in a library package manager.
+The Respository Server is where the [[:Eiffel Library Repository|Eiffel Library Repository]] holds and manages different versions of Eiffel library [[Repository Packages|packages]]. Packages can be uploaded, download and updated using a [[Respository Client Tools|client tool set]].
 == A Better Server ==
@@ Line 10: / Line 10: @@
 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.
-== Uploading Packages ==
+=== Stable Repository ==
 === Holding Area ===