/[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.4 - (show annotations) (download)
Tue Sep 5 20:54:30 2006 UTC (7 years, 10 months ago) by g2boojum
Branch: MAIN
CVS Tags: HEAD
Changes since 1.3: +11 -4 lines
File MIME type: text/plain
Error occurred while calculating annotation data.
updates

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

  ViewVC Help
Powered by ViewVC 1.1.20