| 1 |
GLEP: 50 |
| 2 |
Title: Supporting alternative package managers |
| 3 |
Version: $Revision: 1.3 $ |
| 4 |
Last-Modified: $Date: 2005/11/13 17:16:50 $ |
| 5 |
Author: Grant Goodyear <g2boojum@gentoo.org> |
| 6 |
Status: Draft |
| 7 |
Type: Standards Track |
| 8 |
Content-Type: text/x-rst |
| 9 |
Created: 22-May-2006 |
| 10 |
Post-History: 15-Jun-2006 |
| 11 |
|
| 12 |
Abstract |
| 13 |
======== |
| 14 |
|
| 15 |
To support alternatives to the official package manager (portage, at the time |
| 16 |
of this writing), some sane ground rules need to be set. Specifically, no |
| 17 |
alternative ebuild-based package manager may be added to the tree unless it |
| 18 |
successfully works with all ebuilds supported by the official package manager. |
| 19 |
Moreover, no ebuilds may be added to the tree unless they are supported |
| 20 |
(without change) by the official package manager. |
| 21 |
|
| 22 |
|
| 23 |
Specification |
| 24 |
============= |
| 25 |
|
| 26 |
* No alternative ebuild-based package manager may be added |
| 27 |
to the tree unless it successfully works with all ebuilds supported by |
| 28 |
the official package manager. If an alternative package manager is |
| 29 |
runtime incompatible with the official package manager, then it |
| 30 |
must be masked and provide appropriate warnings. |
| 31 |
* No ebuilds may be added to the tree unless they are supported |
| 32 |
(without change) by the official package manager. |
| 33 |
|
| 34 |
Rationale |
| 35 |
========= |
| 36 |
|
| 37 |
The first rule sets a reasonable bar for adding an alternative package |
| 38 |
manager to the tree. Note that if an ebuild currently in the tree |
| 39 |
doesn't work with the official package manager, it isn't expected to |
| 40 |
work with an alternative package manager either. The second rule |
| 41 |
ensures that an alternative package manager cannot become a de-facto |
| 42 |
requirement by supporting packages that the official package manager |
| 43 |
cannot handle. |
| 44 |
|
| 45 |
In order to keep this proposal as simple and focused as possible, it has |
| 46 |
nothing to say about the process by which an alternative package manager |
| 47 |
might one day become the official package manager. It is assumed that |
| 48 |
sanity will reign, and no package manager will become official without |
| 49 |
being able to build installation media, providing a transition path from |
| 50 |
or to the existing official package manager, etcetera. |
| 51 |
|
| 52 |
Note |
| 53 |
==== |
| 54 |
|
| 55 |
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 |
| 57 |
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 |
| 59 |
eclasses successfully, too. Profiles, on the other hand, are not addressed |
| 60 |
here even implicitly. |
| 61 |
|
| 62 |
Backwards Compatibility |
| 63 |
======================= |
| 64 |
|
| 65 |
Pretty much the whole point, and it's explicit here. |
| 66 |
|
| 67 |
|
| 68 |
Copyright |
| 69 |
========= |
| 70 |
|
| 71 |
This document has been placed in the public domain. |
Parent Directory
| 
Revision Log