Contents of /xml/htdocs/proj/en/glep/glep-0049.txt

Parent Directory Parent Directory | Revision Log Revision Log

Revision 1.1 - (hide annotations) (download)
Sat May 20 12:51:08 2006 UTC (12 years, 6 months ago) by pauldv
Branch: MAIN
File MIME type: text/plain
Add a glep on package managers

1 pauldv 1.1 GLEP: 49
2     Title: Alternative Package Manager requirements
3     Version: $Revision: 2213 $
4     Last-Modified: $Date: 2006-05-19 12:58:14 +0200 (Fri, 19 May 2006) $
5     Author: Paul de Vrieze <pauldv@gentoo.org>,
6     Status: Draft
7     Type: Standards Track
8     Content-Type: text/x-rst
9     Created: 18-May-2006
10     Post-History: 20-May-2006
13     Abstract
14     ========
16     This GLEP describes four classes of package managers. What the requirements for
17     them are, and what support they can receive.
20     Motivation
21     ==========
23     To set a standard that package managers that seek gentoo project approval and
24     support should adhere to.
27     Rationale
28     =========
30     Currently portage is showing its age. The code of portage does not seem to be
31     salvageable for new versions. There are two known alternative package managers
32     that claim a level of portage compatibility. These alternatives are `paludis`_
33     and `pkgcore`_. Before these alternatives are developed further, a set of rules
34     should be created to level the playing field and ensuring that decisions can be
35     made clearly.
38     Backwards Compatibility
39     =======================
41     Not a problem for this GLEP. There is no previous standard as the issue did not
42     exist before. This GLEP is to prevent future compatibility issues.
45     Categories of package managers
46     ==============================
48     We distinguish four categories of package managers. While a package manager can
49     transition from one category to another, it can not be in two categories at the
50     same time. It can be in a state of transition though.
52     *Primary Package Manager*
53     There is one primary package manager. Currently this position is held by
54     portage. The primary package manager is assigned by the council and all
55     packages in the official tree must be installable by a useable version of the
56     primary package manager.
58     *Candidate Primary Package Managers*
59     A candidate Primary Package Manager does aim, or show an aim, at replacing
60     the current primary package manager. At a point where the package manager is
61     deemed stable a decision must be made whether this package manager should
62     become the new primary package manager. At that point the `primary package
63     manager transition phase`_ starts.
65     *Secondary Package Managers*
66     A secondary package manager is a package manager that coexists with the
67     primary package manager, while not aiming to replace it. Package managers
68     that would fall into this category are:
70     - Experimental package managers. Package managers whose purpose it is to try
71     out new features.
73     - Focussed package managers. For example a package manager that allows the
74     use of rpm formatted binary packages would be an example.
77     *Third Party Package Managers*
78     A third party package manager is any package manager that lacks recognition
79     from gentoo as being in any other category. A third party package manager may
80     or may not have a gentoo package, but is not supported beyond that.
83     Package manager requirements
84     ============================
86     As a package manager is in a state of higher support there are higher
87     requirements to it. The purpose of these requirements is to ensure the unity of
88     the distribution and the package tree. For this purpose it is needed that there
89     is only one primary package manager.
92     primary package manager requirements
93     ------------------------------------
95     The primary package manager is the package manager that sets the standards for
96     the tree. All ebuilds in the tree must function with the primary package
97     manager. As the primary package manager sets the standard it does not have to
98     maintain compatibility with other package managers.
100     The primary package manager does however have the responsibility that it must be
101     very stable. The primary package manager must maintain compatibility with old
102     versions of itself for extended periods of time. This compatibilty time is set
103     by the council. The suggested time would be one year from the point that there
104     is a compatible stable version for all supported architectures.
106     Another compatibilty requirement for the primary package manager is a limited
107     forward compatibility. It must always be possible to transition from the
108     unstable version of the primary package manager to a stable version. This may be
109     done either by first introducing reading compatibility for a new format and only
110     having write support later. Another way would be the provision of a conversion
111     tool that ensures that the on disk information maintained by the package manager
112     is supported by the stable package manager.
114     The primary package manager is maintained on official gentoo infrastructure,
115     under control of gentoo developers.
118     candidate primary package manager requirements
119     ------------------------------------------------
121     A candidate primary package manager aims to replace the primary package
122     manager. The council is responsible for deciding whether this is done. The
123     requirements are there to ensure that it is actually possible to transition a
124     candidate primary package manager into the primary package manager.
126     First of all, there must exist a transition path. This means that the on disk
127     data of the primary package manager can be used by (or converted to a format
128     usable by) the candidate primary package manager.
130     Second, there must be a test path. It must be possible for the developers to
131     test out the candidate primary package manager on their working systems. This
132     means that the transition path must exist. This also means that there are no
133     serious obstacles for reverting to the current primary package manager.
135     Third, there must exist an ebuild test path. It must be possible for package
136     managers to test ebuilds in one tree for both the primary as well as the
137     candidate primary package manager. It is not an issue if this requires a special
138     mode for the candidate primary package manager. It is not an issue either if
139     compatibilty can be achieved by unmerging the package in the candidate primary
140     package manager.
142     Fourth, there must be support. This means that the package manager is actively
143     maintained under control of gentoo. If it is not maintained on gentoo
144     infrastructure, the means must be there to move the package manager, with its
145     change history, to gentoo infrastructure. This means that it must be maintained
146     on a gentoo supported versioning system, or on a version system whose history
147     can be converted to a gentoo supported versioning system.
150     secondary package manager requirements
151     --------------------------------------
153     A secondary package manager is a package manager that instead of directly aiming
154     at replacing portage as primary package manager. As such a secondary package
155     manager does not set the standard on the tree, but follows the standard set by
156     the primary package manager.
158     There are two kinds of secondary package managers. The first kind is formed by
159     those that do not maintain their own installed package database, but work with
160     the package database of the primary package manager. While these package
161     managers can put additional information in the database, these entries must
162     remain compatible with the primary package managers. Verification, reference,
163     and deinstallation by the primary package manager must remain functional.
165     The second kind is formed by those package managers that maintain their own
166     package database, or a package database incompatible with the primary package
167     manager. To ensure the secondary role of these package managers the support in
168     the tree for these package manager is provided along with restrictions.
170     The first restriction is that no packages in the tree must rely on the secondary
171     package manager. While packages may provide a level of support (while being
172     compatible with the primary package manager) this may not result in a
173     significant increase of features. If this were allowed, this would mean that
174     while they technically work with the primary package manager, there would be
175     significant incentive to use the secondary package manager. As the use of this
176     secondary package manager disallows the paralel use of the primary package
177     manager, this would result in users using the secondary package manager as their
178     primary package manager.
180     Users are allowed to make their own choices. However by making the tree favor a
181     package manager that is not the primary package manager, this will lead to the
182     secondary package manager becomming the effective primary package manager. As
183     this will be a decision by default instead of a concious choice by the council,
184     this is an undesirable result.
186     There is one exclusion for the restriction of packages that only work with or
187     have significant improvements with the secondary package manager. That is
188     packages that by their nature are only usable with this secondary package
189     manager. An example would be a graphical frontend to the secondary package
190     manager.
192     If a secondary package manager works along the primary package manager, but by
193     itself does not have the capabilities of becoming a primary package manager the
194     risks of choice by default are lower. As a result, the council could choose to
195     allow the inclusion of packages that work only or significantly better with this
196     secondary package manager. For example at a point where there is a stable,
197     functional, package manager that can handle RPM format packages, the council
198     could decide to include these packages directly in the tree, instead of using
199     wrapper scripts for those packages that are only provided in the RPM
200     format. Such a decision does imply that the maintainers of the primary package
201     manager must take this secondary package manager into account.
204     third party package manager requirements
205     ----------------------------------------
207     A third party package manager is just that. It is a package manager without any
208     support within gentoo. As there is no control by gentoo over the package manager
209     this means that there are no requirements on the package manager.
211     This complete lack of control however also translates to the fact that gentoo
212     can not make package manager specific changes to support this package
213     manager. Package manager specific means that it is possible to request changes
214     that make the tree more independent of the primary package manager. These
215     changes must however be agnostic of the package manager, and only make it easier
216     to have alternative package managers.
219     transition phases
220     =================
222     primary package manager transition phase
223     ----------------------------------------
225     A candidate primary package manager can be chosen to become primary package
226     manager. This can only happen by council decision. This decision can only be
227     made when the candiate primary package manager is stable on all stable
228     architectures. (all architectures except experimental ones).
230     After the decision has been made to replace the primary package manager, the
231     transition phase starts. The use of the old stable package manager must remain
232     supported for a period of 6 months. This means that core packages must be
233     installable by this package manager. Further the possibility to convert the
234     system automatically to the new primary package manager must be available for at
235     least 18 months, but preferably longer (enable installing the new package
236     manager from the old one).
238     During the transition phase packages are allowed in the tree that use the new
239     features of the new primary package manager. While backward compatibility with
240     the previous primary package manager must be maintained a forward compatibility
241     is no longer needed.
244     Secondary package manager to candidate primary package manager transition
245     -------------------------------------------------------------------------
247     The transition from secondary package manager to candidate primary package
248     manager is straightforward. The secondary package manager must satisfy all
249     requirements for a candidate primary package manager. At that point its
250     maintainers can announce that they are changing the status to candidate primary
251     package manager. This allows a greater support from gentoo in achieving that
252     goal.
255     Third party to other transition
256     -------------------------------
258     When a third party package manager wants to transition into one of the other
259     categories (except primary package manager) it must satisfy all requirements for
260     that category.
263     References
264     ==========
266     .. _paludis: http://paludis.berlios.de/
267     .. _pkgcore: http://gentooexperimental.org/~ferringb/bzr/pkgcore/
268     .. _Open Publication License: http://www.opencontent.org/openpub/
271     Copyright
272     =========
274     This document is copyright 2006 by Paul de Vrieze and licensed under the
275     `Open Publication License`_.

  ViewVC Help
Powered by ViewVC 1.1.20