| 1 | GLEP: 50 |
1 | GLEP: 50 |
| 2 | Title: Supporting alternative package managers |
2 | Title: Supporting alternative package managers |
| 3 | Version: $Revision: 1.1 $ |
3 | Version: $Revision: 1.3 $ |
| 4 | Last-Modified: $Date: 2006/06/15 14:36:52 $ |
4 | Last-Modified: $Date: 2006/09/05 20:54:30 $ |
| 5 | Author: Grant Goodyear <g2boojum@gentoo.org> |
5 | Author: Grant Goodyear <g2boojum@gentoo.org> |
| 6 | Status: Draft |
6 | Status: Rejected |
| 7 | Type: Standards Track |
7 | Type: Standards Track |
| 8 | Content-Type: text/x-rst |
8 | Content-Type: text/x-rst |
| 9 | Created: 22-May-2006 |
9 | Created: 22-May-2006 |
| 10 | Post-History: 15-Jun-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 | |
| 11 | |
19 | |
| 12 | Abstract |
20 | Abstract |
| 13 | ======== |
21 | ======== |
| 14 | |
22 | |
| 15 | To support alternatives to the official package manager (portage, at the time |
23 | To support alternatives to the official package manager (portage, at the time |
| … | |
… | |
| 47 | might one day become the official package manager. It is assumed that |
55 | might one day become the official package manager. It is assumed that |
| 48 | sanity will reign, and no package manager will become official without |
56 | sanity will reign, and no package manager will become official without |
| 49 | being able to build installation media, providing a transition path from |
57 | being able to build installation media, providing a transition path from |
| 50 | or to the existing official package manager, etcetera. |
58 | or to the existing official package manager, etcetera. |
| 51 | |
59 | |
| 52 | Note |
60 | Notes |
| 53 | ==== |
61 | ===== |
| 54 | |
62 | |
| 55 | An early criticism of this GLEP was that it fails to address eclasses and |
63 | * An early criticism of this GLEP was that it fails to address eclasses and |
| 56 | profiles. As far as eclasses are concerned, my view is that the above rules |
64 | profiles. As far as eclasses are concerned, my view is that the above rules |
| 57 | suffice, since eclasses only matter in their use in ebuilds. If a package |
65 | suffice, since eclasses only matter in their use in ebuilds. If a package |
| 58 | manager can effectively process all ebuilds, then it must be handling the |
66 | manager can effectively process all ebuilds, then it must be handling the |
| 59 | eclasses successfully, too. Profiles, on the other hand, are not addressed |
67 | eclasses successfully, too. Profiles, on the other hand, are not addressed |
| 60 | here even implicitly. |
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". |
| 61 | |
74 | |
| 62 | Backwards Compatibility |
75 | Backwards Compatibility |
| 63 | ======================= |
76 | ======================= |
| 64 | |
77 | |
| 65 | Pretty much the whole point, and it's explicit here. |
78 | Pretty much the whole point, and it's explicit here. |
Parent Directory
| 
Revision Log
| 
Patch