Rename all GLEPs to .rst

1 files changed, 86 insertions, 0 deletions

diff --git a/glep-0050.rst b/glep-0050.rst
new file mode 100644
index 0000000..fa76341
--- /dev/null
+++ b/glep-0050.rst
@@ -0,0 +1,86 @@
+GLEP: 50
+Title: Supporting alternative package managers
+Version: $Revision$
+Last-Modified: $Date$
+Author: Grant Goodyear <g2boojum@gentoo.org>
+Status: Rejected
+Type: Standards Track
+Content-Type: text/x-rst
+Created: 22-May-2006
+Post-History: 15-Jun-2006, 6-Sep-2006
+
+Status
+======
+
+The council rejected this GLEP in favor of starting from a package manager
+API and requiring Gentoo package managers in the tree to support that
+API.  (That API is still pending, however.)
+
+
+Abstract
+========
+
+To support alternatives to the official package manager (portage, at the time
+of this writing), some sane ground rules need to be set.  Specifically, no
+alternative ebuild-based package manager may be added to the tree unless it
+successfully works with all ebuilds supported by the official package manager.
+Moreover, no ebuilds may be added to the tree unless they are supported
+(without change) by the official package manager.
+
+
+Specification
+=============
+
+* No alternative ebuild-based package manager may be added
+  to the tree unless it successfully works with all ebuilds supported by
+  the official package manager.  If an alternative package manager is
+  runtime incompatible with the official package manager, then it
+  must be masked and provide appropriate warnings.
+* No ebuilds may be added to the tree unless they are supported
+  (without change) by the official package manager.
+
+Rationale
+=========
+
+The first rule sets a reasonable bar for adding an alternative package
+manager to the tree.  Note that if an ebuild currently in the tree
+doesn't work with the official package manager, it isn't expected to
+work with an alternative package manager either.  The second rule
+ensures that an alternative package manager cannot become a de-facto
+requirement by supporting packages that the official package manager
+cannot handle.
+
+In order to keep this proposal as simple and focused as possible, it has
+nothing to say about the process by which an alternative package manager
+might one day become the official package manager.  It is assumed that
+sanity will reign, and no package manager will become official without
+being able to build installation media, providing a transition path from
+or to the existing official package manager, etcetera.
+
+Notes
+=====
+
+* An early criticism of this GLEP was that it fails to address eclasses and
+  profiles.  As far as eclasses are concerned, my view is that the above rules
+  suffice, since eclasses only matter in their use in ebuilds.  If a package
+  manager can effectively process all ebuilds, then it must be handling the
+  eclasses successfully, too.  Profiles, on the other hand, are not addressed
+  here even implicitly.
+* Assuming the ebuild specification is successfully finished, then the   
+  first rule should really replace "all ebuilds supported by the official
+  package manager" with "all ebuilds that satisfy the ebuild spec".  
+  Similarly, in rule two "by the official package manager" should
+  read "by the official ebuild spec".
+
+Backwards Compatibility
+=======================
+
+Pretty much the whole point, and it's explicit here.
+
+
+Copyright
+=========
+
+This work is licensed under the Creative Commons Attribution-ShareAlike 3.0
+Unported License.  To view a copy of this license, visit
+http://creativecommons.org/licenses/by-sa/3.0/.