1 |
GLEP: 50 |
2 |
Title: Supporting alternative package managers |
3 |
Version: $Revision: 1.2 $ |
4 |
Last-Modified: $Date: 2006/06/15 15:29:18 $ |
5 |
Author: Grant Goodyear <g2boojum@gentoo.org> |
6 |
Status: Rejected |
7 |
Type: Standards Track |
8 |
Content-Type: text/x-rst |
9 |
Created: 22-May-2006 |
10 |
Post-History: 15-Jun-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 |
To support alternatives to the official package manager (portage, at the time |
24 |
of this writing), some sane ground rules need to be set. Specifically, no |
25 |
alternative ebuild-based package manager may be added to the tree unless it |
26 |
successfully works with all ebuilds supported by the official package manager. |
27 |
Moreover, no ebuilds may be added to the tree unless they are supported |
28 |
(without change) by the official package manager. |
29 |
|
30 |
|
31 |
Specification |
32 |
============= |
33 |
|
34 |
* No alternative ebuild-based package manager may be added |
35 |
to the tree unless it successfully works with all ebuilds supported by |
36 |
the official package manager. If an alternative package manager is |
37 |
runtime incompatible with the official package manager, then it |
38 |
must be masked and provide appropriate warnings. |
39 |
* No ebuilds may be added to the tree unless they are supported |
40 |
(without change) by the official package manager. |
41 |
|
42 |
Rationale |
43 |
========= |
44 |
|
45 |
The first rule sets a reasonable bar for adding an alternative package |
46 |
manager to the tree. Note that if an ebuild currently in the tree |
47 |
doesn't work with the official package manager, it isn't expected to |
48 |
work with an alternative package manager either. The second rule |
49 |
ensures that an alternative package manager cannot become a de-facto |
50 |
requirement by supporting packages that the official package manager |
51 |
cannot handle. |
52 |
|
53 |
In order to keep this proposal as simple and focused as possible, it has |
54 |
nothing to say about the process by which an alternative package manager |
55 |
might one day become the official package manager. It is assumed that |
56 |
sanity will reign, and no package manager will become official without |
57 |
being able to build installation media, providing a transition path from |
58 |
or to the existing official package manager, etcetera. |
59 |
|
60 |
Notes |
61 |
===== |
62 |
|
63 |
* An early criticism of this GLEP was that it fails to address eclasses and |
64 |
profiles. As far as eclasses are concerned, my view is that the above rules |
65 |
suffice, since eclasses only matter in their use in ebuilds. If a package |
66 |
manager can effectively process all ebuilds, then it must be handling the |
67 |
eclasses successfully, too. Profiles, on the other hand, are not addressed |
68 |
here even implicitly. |
69 |
* Assuming the ebuild specification is successfully finished, then the |
70 |
first rule should really replace "all ebuilds supported by the official |
71 |
package manager" with "all ebuilds that satisfy the ebuild spec". |
72 |
Similarly, in rule two "by the official package manager" should |
73 |
read "by the official ebuild spec". |
74 |
|
75 |
Backwards Compatibility |
76 |
======================= |
77 |
|
78 |
Pretty much the whole point, and it's explicit here. |
79 |
|
80 |
|
81 |
Copyright |
82 |
========= |
83 |
|
84 |
This document has been placed in the public domain. |