/[gentoo]/xml/htdocs/proj/en/glep/glep-0049.txt
Gentoo

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

Parent Directory Parent Directory | Revision Log Revision Log


Revision 1.3 - (hide annotations) (download)
Sun May 21 10:23:55 2006 UTC (8 years, 7 months ago) by pauldv
Branch: MAIN
Changes since 1.2: +20 -8 lines
File MIME type: text/plain
Fixes for feedback from the email list

1 pauldv 1.1 GLEP: 49
2     Title: Alternative Package Manager requirements
3 pauldv 1.3 Version: $Revision: 2218 $
4     Last-Modified: $Date: 2006-05-20 20:39:14 +0200 (Sat, 20 May 2006) $
5 pauldv 1.1 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 pauldv 1.2 Post-History: 19-May-2006
11 pauldv 1.1
12    
13     Abstract
14     ========
15    
16     This GLEP describes four classes of package managers. What the requirements for
17     them are, and what support they can receive.
18    
19    
20     Motivation
21     ==========
22    
23 pauldv 1.2 To set a standard that package managers that seek Gentoo project approval and
24 pauldv 1.1 support should adhere to.
25    
26    
27     Rationale
28     =========
29    
30 pauldv 1.2 Currently Portage is showing its age. The code of Portage does not seem to be
31     salvageable for new versions. As of the date of publication, there are two known
32     alternative package managers that claim a level of Portage compatibility. These
33     alternatives are `paludis`_ and `pkgcore`_. Before these alternatives are
34     developed further, a set of rules should be created to level the playing field
35     and ensuring that decisions can be made clearly.
36 pauldv 1.1
37    
38     Backwards Compatibility
39     =======================
40    
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.
43    
44    
45     Categories of package managers
46     ==============================
47    
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.
51    
52     *Primary Package Manager*
53     There is one primary package manager. Currently this position is held by
54 pauldv 1.2 Portage. The primary package manager is assigned by the council and all
55     packages in the official tree must be installable by a usable version of the
56 pauldv 1.1 primary package manager.
57    
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 pauldv 1.2 become the new primary package manager. At that point the `Primary package
63 pauldv 1.1 manager transition phase`_ starts.
64    
65     *Secondary Package Managers*
66     A secondary package manager is a package manager that coexists with the
67 pauldv 1.2 primary package manager, while not aiming to replace it. Examples of package
68     managers that would fall into this category are:
69 pauldv 1.1
70     - Experimental package managers. Package managers whose purpose it is to try
71     out new features.
72    
73 pauldv 1.2 - Focused package managers. For example a package manager that allows the
74     use of RPM formatted binary packages would be an example.
75    
76     - Alternate package managers. Package managers that aim to coexist with the
77     primary package manager. They might for example offer a nicer user
78     interface than the primary package manager (e.g. show a cow instead of
79     compilation messages).
80 pauldv 1.1
81    
82     *Third Party Package Managers*
83     A third party package manager is any package manager that lacks recognition
84 pauldv 1.2 from Gentoo as being in any other category. A third party package manager may
85     or may not have a Gentoo package, but is not supported beyond that.
86 pauldv 1.1
87    
88     Package manager requirements
89     ============================
90    
91     As a package manager is in a state of higher support there are higher
92     requirements to it. The purpose of these requirements is to ensure the unity of
93     the distribution and the package tree. For this purpose it is needed that there
94 pauldv 1.3 is only one primary package manager. This is from gentoo's perspective. From a
95     user perspective it is perfectly possible to use another package
96     manager. Candidate primary package managers and secondary package managers are
97     also supported in regards to bugs etc.
98 pauldv 1.1
99    
100 pauldv 1.2 Primary package manager requirements
101 pauldv 1.1 ------------------------------------
102    
103     The primary package manager is the package manager that sets the standards for
104     the tree. All ebuilds in the tree must function with the primary package
105     manager. As the primary package manager sets the standard it does not have to
106 pauldv 1.3 maintain compatibility with other package managers. This does not mean that the
107     actual implementation is the standard, but that the maintainers have the ability
108     to define new standards, together with the other involved gentoo projects.
109 pauldv 1.1
110     The primary package manager does however have the responsibility that it must be
111     very stable. The primary package manager must maintain compatibility with old
112 pauldv 1.2 versions of itself for extended periods of time. This compatibility time is set
113 pauldv 1.1 by the council. The suggested time would be one year from the point that there
114     is a compatible stable version for all supported architectures.
115    
116 pauldv 1.2 Another compatibility requirement for the primary package manager is a limited
117 pauldv 1.1 forward compatibility. It must always be possible to transition from the
118     unstable version of the primary package manager to a stable version. This may be
119     done either by first introducing reading compatibility for a new format and only
120     having write support later. Another way would be the provision of a conversion
121     tool that ensures that the on disk information maintained by the package manager
122     is supported by the stable package manager.
123    
124 pauldv 1.3 The primary package manager maintainers further have the responsibility to allow
125     competition. This means that reasonable patches from the maintainers of
126     secondary or candidate primary package managers must be applied, given that
127     these patches are as independent of that package manager as possible.
128    
129 pauldv 1.2 The primary package manager is maintained on official Gentoo infrastructure,
130     under control of Gentoo developers.
131 pauldv 1.1
132    
133 pauldv 1.2 Candidate primary package manager requirements
134 pauldv 1.1 ------------------------------------------------
135    
136     A candidate primary package manager aims to replace the primary package
137     manager. The council is responsible for deciding whether this is done. The
138     requirements are there to ensure that it is actually possible to transition a
139     candidate primary package manager into the primary package manager.
140    
141     First of all, there must exist a transition path. This means that the on disk
142     data of the primary package manager can be used by (or converted to a format
143     usable by) the candidate primary package manager.
144    
145     Second, there must be a test path. It must be possible for the developers to
146     test out the candidate primary package manager on their working systems. This
147     means that the transition path must exist. This also means that there are no
148 pauldv 1.2 serious obstacles for reverting to the current primary package manager. This
149     reverting must also be usable when it is decided that the candidate will not
150     become primary package manager, for example because serious design flaws or bugs
151     were found. Ideally, the Candidate Primary Package Manager and the Primary
152     Package Manager can be installed simultaneously. If not, clear instructions must
153     be provided for both ways of transitioning.
154 pauldv 1.1
155     Third, there must exist an ebuild test path. It must be possible for package
156     managers to test ebuilds in one tree for both the primary as well as the
157     candidate primary package manager. It is not an issue if this requires a special
158     mode for the candidate primary package manager. It is not an issue either if
159 pauldv 1.2 compatibility can be achieved by having the candidate primary package manager
160     unmerge the package.
161 pauldv 1.1
162     Fourth, there must be support. This means that the package manager is actively
163 pauldv 1.2 maintained under control of Gentoo. If it is not maintained on Gentoo
164 pauldv 1.1 infrastructure, the means must be there to move the package manager, with its
165 pauldv 1.2 change history, to Gentoo infrastructure. This means that it must be maintained
166     on a Gentoo supported versioning system, or on a version system whose history
167     can be converted to a Gentoo supported versioning system.
168    
169     Fifth, release capabilities. There must exist automated tools that use the
170     candidate primary package manager to create release media that have similar
171     capabilities as those released using the old primary package manager. The exact
172     requirements are determined by the Release Engineering project, but should not
173     be significantly beyond what is currently implemented using the primary package
174     manager.
175 pauldv 1.1
176    
177 pauldv 1.2 Secondary package manager requirements
178 pauldv 1.1 --------------------------------------
179    
180     A secondary package manager is a package manager that instead of directly aiming
181 pauldv 1.2 at replacing the current primary package manager as primary package manager aims
182     to cooperate with the primary package manager. As such a secondary package
183 pauldv 1.1 manager does not set the standard on the tree, but follows the standard set by
184     the primary package manager.
185    
186     There are two kinds of secondary package managers. The first kind is formed by
187     those that do not maintain their own installed package database, but work with
188     the package database of the primary package manager. While these package
189     managers can put additional information in the database, these entries must
190     remain compatible with the primary package managers. Verification, reference,
191     and deinstallation by the primary package manager must remain functional.
192    
193     The second kind is formed by those package managers that maintain their own
194     package database, or a package database incompatible with the primary package
195     manager. To ensure the secondary role of these package managers the support in
196 pauldv 1.3 the tree for these package managers is provided along with restrictions.
197 pauldv 1.1
198     The first restriction is that no packages in the tree must rely on the secondary
199     package manager. While packages may provide a level of support (while being
200     compatible with the primary package manager) this may not result in a
201 pauldv 1.2 significant increase of features. If this were allowed, this would mean that
202 pauldv 1.1 while they technically work with the primary package manager, there would be
203     significant incentive to use the secondary package manager. As the use of this
204 pauldv 1.2 secondary package manager disallows the parallel use of the primary package
205 pauldv 1.1 manager, this would result in users using the secondary package manager as their
206     primary package manager.
207    
208 pauldv 1.2 Users are allowed to make their own choices. However by making the tree favour a
209 pauldv 1.1 package manager that is not the primary package manager, this will lead to the
210 pauldv 1.2 secondary package manager becoming the effective primary package manager. As
211     this will be a decision by default instead of a conscious choice by the council,
212 pauldv 1.1 this is an undesirable result.
213    
214     There is one exclusion for the restriction of packages that only work with or
215     have significant improvements with the secondary package manager. That is
216     packages that by their nature are only usable with this secondary package
217 pauldv 1.2 manager. An example would be a graphical front-end to the secondary package
218 pauldv 1.1 manager.
219    
220     If a secondary package manager works along the primary package manager, but by
221     itself does not have the capabilities of becoming a primary package manager the
222     risks of choice by default are lower. As a result, the council could choose to
223     allow the inclusion of packages that work only or significantly better with this
224     secondary package manager. For example at a point where there is a stable,
225     functional, package manager that can handle RPM format packages, the council
226     could decide to include these packages directly in the tree, instead of using
227     wrapper scripts for those packages that are only provided in the RPM
228     format. Such a decision does imply that the maintainers of the primary package
229     manager must take this secondary package manager into account.
230    
231    
232 pauldv 1.2 Third party package manager requirements
233 pauldv 1.1 ----------------------------------------
234    
235     A third party package manager is just that. It is a package manager without any
236 pauldv 1.2 support within Gentoo. As there is no control by Gentoo over the package manager
237 pauldv 1.1 this means that there are no requirements on the package manager.
238    
239 pauldv 1.2 This complete lack of control however also translates to the fact that Gentoo
240 pauldv 1.1 can not make package manager specific changes to support this package
241     manager. Package manager specific means that it is possible to request changes
242     that make the tree more independent of the primary package manager. These
243     changes must however be agnostic of the package manager, and only make it easier
244     to have alternative package managers.
245    
246    
247 pauldv 1.2 Transition phases
248 pauldv 1.1 =================
249    
250 pauldv 1.2 Primary package manager transition phase
251 pauldv 1.1 ----------------------------------------
252    
253     A candidate primary package manager can be chosen to become primary package
254 pauldv 1.3 manager. This can only happen by council decision. This decision can only be
255     made when the candidate primary package manager is stable on all stable
256     architectures. (all architectures except experimental ones). There is a
257     incubation period of at least 3 months before a candidate primary package
258     manager can become the primary package manager.
259 pauldv 1.1
260     After the decision has been made to replace the primary package manager, the
261     transition phase starts. The use of the old stable package manager must remain
262     supported for a period of 6 months. This means that core packages must be
263     installable by this package manager. Further the possibility to convert the
264     system automatically to the new primary package manager must be available for at
265     least 18 months, but preferably longer (enable installing the new package
266     manager from the old one).
267    
268     During the transition phase packages are allowed in the tree that use the new
269     features of the new primary package manager. While backward compatibility with
270     the previous primary package manager must be maintained a forward compatibility
271     is no longer needed.
272    
273    
274     Secondary package manager to candidate primary package manager transition
275     -------------------------------------------------------------------------
276    
277     The transition from secondary package manager to candidate primary package
278     manager is straightforward. The secondary package manager must satisfy all
279     requirements for a candidate primary package manager. At that point its
280     maintainers can announce that they are changing the status to candidate primary
281 pauldv 1.2 package manager. This allows a greater support from Gentoo in achieving that
282 pauldv 1.1 goal.
283    
284    
285     Third party to other transition
286     -------------------------------
287    
288     When a third party package manager wants to transition into one of the other
289     categories (except primary package manager) it must satisfy all requirements for
290     that category.
291    
292    
293     References
294     ==========
295    
296     .. _paludis: http://paludis.berlios.de/
297     .. _pkgcore: http://gentooexperimental.org/~ferringb/bzr/pkgcore/
298     .. _Open Publication License: http://www.opencontent.org/openpub/
299    
300    
301     Copyright
302     =========
303    
304     This document is copyright 2006 by Paul de Vrieze and licensed under the
305     `Open Publication License`_.

  ViewVC Help
Powered by ViewVC 1.1.20