diff options
Diffstat (limited to 'xml/htdocs/proj/en/glep/glep-0049.html')
| -rw-r--r-- | xml/htdocs/proj/en/glep/glep-0049.html | 352 |
1 files changed, 352 insertions, 0 deletions
diff --git a/xml/htdocs/proj/en/glep/glep-0049.html b/xml/htdocs/proj/en/glep/glep-0049.html new file mode 100644 index 00000000..f0baa1ce --- /dev/null +++ b/xml/htdocs/proj/en/glep/glep-0049.html @@ -0,0 +1,352 @@ +<?xml version="1.0" encoding="utf-8" ?> +<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> +<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"> + +<head> + <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> + <meta name="generator" content="Docutils 0.4: http://docutils.sourceforge.net/" /> + <title>GLEP 49 -- Alternative Package Manager requirements</title> + <link rel="stylesheet" href="tools/glep.css" type="text/css" /> +</head> +<body bgcolor="white"> +<table class="navigation" cellpadding="0" cellspacing="0" + width="100%" border="0"> +<tr><td class="navicon" width="150" height="35"> +<a href="http://www.gentoo.org/" title="Gentoo Linux Home Page"> +<img src="http://www.gentoo.org/images/gentoo-new.gif" alt="[Gentoo]" + border="0" width="150" height="35" /></a></td> +<td class="textlinks" align="left"> +[<b><a href="http://www.gentoo.org/">Gentoo Linux Home</a></b>] +[<b><a href="http://www.gentoo.org/proj/en/glep">GLEP Index</a></b>] +[<b><a href="http://www.gentoo.org/proj/en/glep/glep-0049.txt">GLEP Source</a></b>] +</td></tr></table> +<table class="rfc2822 docutils field-list" frame="void" rules="none"> +<col class="field-name" /> +<col class="field-body" /> +<tbody valign="top"> +<tr class="field"><th class="field-name">GLEP:</th><td class="field-body">49</td> +</tr> +<tr class="field"><th class="field-name">Title:</th><td class="field-body">Alternative Package Manager requirements</td> +</tr> +<tr class="field"><th class="field-name">Version:</th><td class="field-body">1.4</td> +</tr> +<tr class="field"><th class="field-name">Last-Modified:</th><td class="field-body"><a class="reference" href="http://www.gentoo.org/cgi-bin/viewcvs.cgi/xml/htdocs/proj/en/glep/glep-0049.txt?cvsroot=gentoo">2006/09/05 20:54:30</a></td> +</tr> +<tr class="field"><th class="field-name">Author:</th><td class="field-body">Paul de Vrieze <pauldv at gentoo.org>,</td> +</tr> +<tr class="field"><th class="field-name">Status:</th><td class="field-body">Rejected</td> +</tr> +<tr class="field"><th class="field-name">Type:</th><td class="field-body">Standards Track</td> +</tr> +<tr class="field"><th class="field-name">Content-Type:</th><td class="field-body"><a class="reference" href="glep-0002.html">text/x-rst</a></td> +</tr> +<tr class="field"><th class="field-name">Created:</th><td class="field-body">18-May-2006</td> +</tr> +<tr class="field"><th class="field-name">Post-History:</th><td class="field-body">19-May-2006, 6-Sep-2006</td> +</tr> +</tbody> +</table> +<hr /> +<div class="contents topic"> +<p class="topic-title first"><a id="contents" name="contents">Contents</a></p> +<ul class="simple"> +<li><a class="reference" href="#status" id="id7" name="id7">Status</a></li> +<li><a class="reference" href="#abstract" id="id8" name="id8">Abstract</a></li> +<li><a class="reference" href="#motivation" id="id9" name="id9">Motivation</a></li> +<li><a class="reference" href="#rationale" id="id10" name="id10">Rationale</a></li> +<li><a class="reference" href="#backwards-compatibility" id="id11" name="id11">Backwards Compatibility</a></li> +<li><a class="reference" href="#categories-of-package-managers" id="id12" name="id12">Categories of package managers</a></li> +<li><a class="reference" href="#package-manager-requirements" id="id13" name="id13">Package manager requirements</a><ul> +<li><a class="reference" href="#primary-package-manager-requirements" id="id14" name="id14">Primary package manager requirements</a></li> +<li><a class="reference" href="#candidate-primary-package-manager-requirements" id="id15" name="id15">Candidate primary package manager requirements</a></li> +<li><a class="reference" href="#secondary-package-manager-requirements" id="id16" name="id16">Secondary package manager requirements</a></li> +<li><a class="reference" href="#third-party-package-manager-requirements" id="id17" name="id17">Third party package manager requirements</a></li> +</ul> +</li> +<li><a class="reference" href="#transition-phases" id="id18" name="id18">Transition phases</a><ul> +<li><a class="reference" href="#primary-package-manager-transition-phase" id="id19" name="id19">Primary package manager transition phase</a></li> +<li><a class="reference" href="#secondary-package-manager-to-candidate-primary-package-manager-transition" id="id20" name="id20">Secondary package manager to candidate primary package manager transition</a></li> +<li><a class="reference" href="#third-party-to-other-transition" id="id21" name="id21">Third party to other transition</a></li> +</ul> +</li> +<li><a class="reference" href="#references" id="id22" name="id22">References</a></li> +<li><a class="reference" href="#copyright" id="id23" name="id23">Copyright</a></li> +</ul> +</div> +<div class="section"> +<h1><a class="toc-backref" href="#id7" id="status" name="status">Status</a></h1> +<p>The council rejected this GLEP in favor of starting from a package manager +API and requiring Gentoo package managers in the tree to support that +API. (That API is still pending, however.)</p> +</div> +<div class="section"> +<h1><a class="toc-backref" href="#id8" id="abstract" name="abstract">Abstract</a></h1> +<p>This GLEP describes four classes of package managers. What the requirements for +them are, and what support they can receive.</p> +</div> +<div class="section"> +<h1><a class="toc-backref" href="#id9" id="motivation" name="motivation">Motivation</a></h1> +<p>To set a standard that package managers that seek Gentoo project approval and +support should adhere to.</p> +</div> +<div class="section"> +<h1><a class="toc-backref" href="#id10" id="rationale" name="rationale">Rationale</a></h1> +<p>Currently Portage is showing its age. The code of Portage does not seem to be +salvageable for new versions. As of the date of publication, there are two known +alternative package managers that claim a level of Portage compatibility. These +alternatives are <a class="reference" href="http://paludis.berlios.de/">paludis</a> <a class="footnote-reference" href="#id1" id="id2" name="id2">[1]</a> and <a class="reference" href="http://gentooexperimental.org/~ferringb/bzr/pkgcore/">pkgcore</a> <a class="footnote-reference" href="#id3" id="id4" name="id4">[2]</a>. Before these alternatives are +developed further, a set of rules should be created to level the playing field +and ensuring that decisions can be made clearly.</p> +</div> +<div class="section"> +<h1><a class="toc-backref" href="#id11" id="backwards-compatibility" name="backwards-compatibility">Backwards Compatibility</a></h1> +<p>Not a problem for this GLEP. There is no previous standard as the issue did not +exist before. This GLEP is to prevent future compatibility issues.</p> +</div> +<div class="section"> +<h1><a class="toc-backref" href="#id12" id="categories-of-package-managers" name="categories-of-package-managers">Categories of package managers</a></h1> +<p>We distinguish four categories of package managers. While a package manager can +transition from one category to another, it can not be in two categories at the +same time. It can be in a state of transition though.</p> +<dl class="docutils"> +<dt><em>Primary Package Manager</em></dt> +<dd>There is one primary package manager. Currently this position is held by +Portage. The primary package manager is assigned by the council and all +packages in the official tree must be installable by a usable version of the +primary package manager.</dd> +<dt><em>Candidate Primary Package Managers</em></dt> +<dd>A candidate Primary Package Manager does aim, or show an aim, at replacing +the current primary package manager. At a point where the package manager is +deemed stable a decision must be made whether this package manager should +become the new primary package manager. At that point the <a class="reference" href="#primary-package-manager-transition-phase">Primary package +manager transition phase</a> starts.</dd> +<dt><em>Secondary Package Managers</em></dt> +<dd><p class="first">A secondary package manager is a package manager that coexists with the +primary package manager, while not aiming to replace it. Examples of package +managers that would fall into this category are:</p> +<ul class="last simple"> +<li>Experimental package managers. Package managers whose purpose it is to try +out new features.</li> +<li>Focused package managers. For example a package manager that allows the +use of RPM formatted binary packages would be an example.</li> +<li>Alternate package managers. Package managers that aim to coexist with the +primary package manager. They might for example offer a nicer user +interface than the primary package manager (e.g. show a cow instead of +compilation messages).</li> +</ul> +</dd> +<dt><em>Third Party Package Managers</em></dt> +<dd>A third party package manager is any package manager that lacks recognition +from Gentoo as being in any other category. A third party package manager may +or may not have a Gentoo package, but is not supported beyond that.</dd> +</dl> +</div> +<div class="section"> +<h1><a class="toc-backref" href="#id13" id="package-manager-requirements" name="package-manager-requirements">Package manager requirements</a></h1> +<p>As a package manager is in a state of higher support there are higher +requirements to it. The purpose of these requirements is to ensure the unity of +the distribution and the package tree. For this purpose it is needed that there +is only one primary package manager. This is from gentoo's perspective. From a +user perspective it is perfectly possible to use another package +manager. Candidate primary package managers and secondary package managers are +also supported in regards to bugs etc.</p> +<div class="section"> +<h2><a class="toc-backref" href="#id14" id="primary-package-manager-requirements" name="primary-package-manager-requirements">Primary package manager requirements</a></h2> +<p>The primary package manager is the package manager that sets the standards for +the tree. All ebuilds in the tree must function with the primary package +manager. As the primary package manager sets the standard it does not have to +maintain compatibility with other package managers. This does not mean that the +actual implementation is the standard, but that the maintainers have the ability +to define new standards, together with the other involved gentoo projects.</p> +<p>The primary package manager does however have the responsibility that it must be +very stable. The primary package manager must maintain compatibility with old +versions of itself for extended periods of time. This compatibility time is set +by the council. The suggested time would be one year from the point that there +is a compatible stable version for all supported architectures.</p> +<p>Another compatibility requirement for the primary package manager is a limited +forward compatibility. It must always be possible to transition from the +unstable version of the primary package manager to a stable version. This may be +done either by first introducing reading compatibility for a new format and only +having write support later. Another way would be the provision of a conversion +tool that ensures that the on disk information maintained by the package manager +is supported by the stable package manager.</p> +<p>The primary package manager maintainers further have the responsibility to allow +competition. This means that reasonable patches from the maintainers of +secondary or candidate primary package managers must be applied, given that +these patches are as independent of that package manager as possible.</p> +<p>The primary package manager is maintained on official Gentoo infrastructure, +under control of Gentoo developers.</p> +</div> +<div class="section"> +<h2><a class="toc-backref" href="#id15" id="candidate-primary-package-manager-requirements" name="candidate-primary-package-manager-requirements">Candidate primary package manager requirements</a></h2> +<p>A candidate primary package manager aims to replace the primary package +manager. The council is responsible for deciding whether this is done. The +requirements are there to ensure that it is actually possible to transition a +candidate primary package manager into the primary package manager.</p> +<p>First of all, there must exist a transition path. This means that the on disk +data of the primary package manager can be used by (or converted to a format +usable by) the candidate primary package manager.</p> +<p>Second, there must be a test path. It must be possible for the developers to +test out the candidate primary package manager on their working systems. This +means that the transition path must exist. This also means that there are no +serious obstacles for reverting to the current primary package manager. This +reverting must also be usable when it is decided that the candidate will not +become primary package manager, for example because serious design flaws or bugs +were found. Ideally, the Candidate Primary Package Manager and the Primary +Package Manager can be installed simultaneously. If not, clear instructions must +be provided for both ways of transitioning.</p> +<p>Third, there must exist an ebuild test path. It must be possible for package +managers to test ebuilds in one tree for both the primary as well as the +candidate primary package manager. It is not an issue if this requires a special +mode for the candidate primary package manager. It is not an issue either if +compatibility can be achieved by having the candidate primary package manager +unmerge the package.</p> +<p>Fourth, there must be support. This means that the package manager is actively +maintained under control of Gentoo. If it is not maintained on Gentoo +infrastructure, the means must be there to move the package manager, with its +change history, to Gentoo infrastructure. This means that it must be maintained +on a Gentoo supported versioning system, or on a version system whose history +can be converted to a Gentoo supported versioning system.</p> +<p>Fifth, release capabilities. There must exist automated tools that use the +candidate primary package manager to create release media that have similar +capabilities as those released using the old primary package manager. The exact +requirements are determined by the Release Engineering project, but should not +be significantly beyond what is currently implemented using the primary package +manager.</p> +</div> +<div class="section"> +<h2><a class="toc-backref" href="#id16" id="secondary-package-manager-requirements" name="secondary-package-manager-requirements">Secondary package manager requirements</a></h2> +<p>A secondary package manager is a package manager that instead of directly aiming +at replacing the current primary package manager as primary package manager aims +to cooperate with the primary package manager. As such a secondary package +manager does not set the standard on the tree, but follows the standard set by +the primary package manager.</p> +<p>There are two kinds of secondary package managers. The first kind is formed by +those that do not maintain their own installed package database, but work with +the package database of the primary package manager. While these package +managers can put additional information in the database, these entries must +remain compatible with the primary package managers. Verification, reference, +and deinstallation by the primary package manager must remain functional.</p> +<p>The second kind is formed by those package managers that maintain their own +package database, or a package database incompatible with the primary package +manager. To ensure the secondary role of these package managers the support in +the tree for these package managers is provided along with restrictions.</p> +<p>The first restriction is that no packages in the tree must rely on the secondary +package manager. While packages may provide a level of support (while being +compatible with the primary package manager) this may not result in a +significant increase of features. If this were allowed, this would mean that +while they technically work with the primary package manager, there would be +significant incentive to use the secondary package manager. As the use of this +secondary package manager disallows the parallel use of the primary package +manager, this would result in users using the secondary package manager as their +primary package manager.</p> +<p>Users are allowed to make their own choices. However by making the tree favour a +package manager that is not the primary package manager, this will lead to the +secondary package manager becoming the effective primary package manager. As +this will be a decision by default instead of a conscious choice by the council, +this is an undesirable result.</p> +<p>There is one exclusion for the restriction of packages that only work with or +have significant improvements with the secondary package manager. That is +packages that by their nature are only usable with this secondary package +manager. An example would be a graphical front-end to the secondary package +manager.</p> +<p>If a secondary package manager works along the primary package manager, but by +itself does not have the capabilities of becoming a primary package manager the +risks of choice by default are lower. As a result, the council could choose to +allow the inclusion of packages that work only or significantly better with this +secondary package manager. For example at a point where there is a stable, +functional, package manager that can handle RPM format packages, the council +could decide to include these packages directly in the tree, instead of using +wrapper scripts for those packages that are only provided in the RPM +format. Such a decision does imply that the maintainers of the primary package +manager must take this secondary package manager into account.</p> +</div> +<div class="section"> +<h2><a class="toc-backref" href="#id17" id="third-party-package-manager-requirements" name="third-party-package-manager-requirements">Third party package manager requirements</a></h2> +<p>A third party package manager is just that. It is a package manager without any +support within Gentoo. As there is no control by Gentoo over the package manager +this means that there are no requirements on the package manager.</p> +<p>This complete lack of control however also translates to the fact that Gentoo +can not make package manager specific changes to support this package +manager. Package manager specific means that it is possible to request changes +that make the tree more independent of the primary package manager. These +changes must however be agnostic of the package manager, and only make it easier +to have alternative package managers.</p> +</div> +</div> +<div class="section"> +<h1><a class="toc-backref" href="#id18" id="transition-phases" name="transition-phases">Transition phases</a></h1> +<div class="section"> +<h2><a class="toc-backref" href="#id19" id="primary-package-manager-transition-phase" name="primary-package-manager-transition-phase">Primary package manager transition phase</a></h2> +<p>A candidate primary package manager can be chosen to become primary package +manager. This can only happen by council decision. This decision can only be +made when the candidate primary package manager is stable on all stable +architectures. (all architectures except experimental ones). There is a +incubation period of at least 3 months before a candidate primary package +manager can become the primary package manager.</p> +<p>After the decision has been made to replace the primary package manager, the +transition phase starts. The use of the old stable package manager must remain +supported for a period of 6 months. This means that core packages must be +installable by this package manager. Further the possibility to convert the +system automatically to the new primary package manager must be available for at +least 18 months, but preferably longer (enable installing the new package +manager from the old one).</p> +<p>During the transition phase packages are allowed in the tree that use the new +features of the new primary package manager. While backward compatibility with +the previous primary package manager must be maintained a forward compatibility +is no longer needed.</p> +</div> +<div class="section"> +<h2><a class="toc-backref" href="#id20" id="secondary-package-manager-to-candidate-primary-package-manager-transition" name="secondary-package-manager-to-candidate-primary-package-manager-transition">Secondary package manager to candidate primary package manager transition</a></h2> +<p>The transition from secondary package manager to candidate primary package +manager is straightforward. The secondary package manager must satisfy all +requirements for a candidate primary package manager. At that point its +maintainers can announce that they are changing the status to candidate primary +package manager. This allows a greater support from Gentoo in achieving that +goal.</p> +</div> +<div class="section"> +<h2><a class="toc-backref" href="#id21" id="third-party-to-other-transition" name="third-party-to-other-transition">Third party to other transition</a></h2> +<p>When a third party package manager wants to transition into one of the other +categories (except primary package manager) it must satisfy all requirements for +that category.</p> +</div> +</div> +<div class="section"> +<h1><a class="toc-backref" href="#id22" id="references" name="references">References</a></h1> +<table class="docutils footnote" frame="void" id="id1" rules="none"> +<colgroup><col class="label" /><col /></colgroup> +<tbody valign="top"> +<tr><td class="label"><a class="fn-backref" href="#id2" name="id1">[1]</a></td><td><a class="reference" href="http://paludis.berlios.de/">http://paludis.berlios.de/</a></td></tr> +</tbody> +</table> +<table class="docutils footnote" frame="void" id="id3" rules="none"> +<colgroup><col class="label" /><col /></colgroup> +<tbody valign="top"> +<tr><td class="label"><a class="fn-backref" href="#id4" name="id3">[2]</a></td><td><a class="reference" href="http://gentooexperimental.org/~ferringb/bzr/pkgcore/">http://gentooexperimental.org/~ferringb/bzr/pkgcore/</a></td></tr> +</tbody> +</table> +<table class="docutils footnote" frame="void" id="id5" rules="none"> +<colgroup><col class="label" /><col /></colgroup> +<tbody valign="top"> +<tr><td class="label"><a class="fn-backref" href="#id6" name="id5">[3]</a></td><td><a class="reference" href="http://www.opencontent.org/openpub/">http://www.opencontent.org/openpub/</a></td></tr> +</tbody> +</table> +</div> +<div class="section"> +<h1><a class="toc-backref" href="#id23" id="copyright" name="copyright">Copyright</a></h1> +<p>This document is copyright 2006 by Paul de Vrieze and licensed under the +<a class="reference" href="http://www.opencontent.org/openpub/">Open Publication License</a> <a class="footnote-reference" href="#id5" id="id6" name="id6">[3]</a>.</p> +</div> + +</div> +<div class="footer"> +<hr class="footer" /> +<a class="reference" href="glep-0049.txt">View document source</a>. +Generated on: 2007-10-13 13:39 UTC. +Generated by <a class="reference" href="http://docutils.sourceforge.net/">Docutils</a> from <a class="reference" href="http://docutils.sourceforge.net/rst.html">reStructuredText</a> source. + +</div> +</body> +</html> + |