Rename all GLEPs to .rst

1 files changed, 120 insertions, 0 deletions

diff --git a/glep-0024.rst b/glep-0024.rst
new file mode 100644
index 0000000..ce17844
--- /dev/null
+++ b/glep-0024.rst
@@ -0,0 +1,120 @@
+GLEP: 24
+Title: Consistent Gentoo tool naming scheme
+Version: $Revision$
+Last-Modified: $Date$
+Author: Donnie Berkholz <dberkholz@gentoo.org>,
+Status: Deferred
+Type: Standards Track
+Content-Type: text/x-rst
+Created: 16 March 2004
+Post-History: 17-Mar-2004, 25-Oct-2004
+
+
+Abstract
+========
+
+This GLEP proposes to create a more consistent, logical and usable naming
+scheme for Gentoo-specific configuration and update tools. It proposes
+changing the scheme to gentoo-config-<toolname> and gentoo-update-<toolname>.
+
+Status Update
+=============
+
+The author notes that this GLEP "needs significant work", which is
+unlikely to occur until either winter vacation or next summer.
+Marking as deferred for the time being.
+
+
+Motivation
+==========
+
+A consistent prefix on these tools will allow users to easily find them on the
+system by merely entering "gentoo-<tab><tab>" for a complete listing or
+"gentoo-config-<tab><tab>" or "gentoo-update-<tab><tab>" to get a listing of
+the specific category.
+
+In the current situation, it is trivial to miss a configuration tool unless one
+reads a portage log of installed files for a package. Revamping the naming
+scheme would enable users to find these tools more easily.
+
+
+Specification
+=============
+
+The following packages and tools are affected (gentoo- prefix removed for ease
+of reading, current name follows suggested name)::
+
+    config-kernel
+    x11-base/opengl-update -> config-opengl (opengl-update)
+    sys-devel/distcc -> config-distcc (distcc-config)
+    app-admin/zope-config -> config-zope (zope-config)
+    app-sci/blas-config -> config-blas (blas-config)
+    dev-java/java-config -> config-java (java-config)
+    dev-ruby/ruby-config -> config-ruby (ruby-config)
+    net-www/webapp-config -> config-webapp (webapp-config)
+    sys-devel/cc-config -> config-cc (cc-config)
+    sys-devel/gcc-config -> config-gcc (gcc-config)
+    dev-lang/python -> update-python (python-updater)
+    sys-apps/baselayout -> update-modules (modules-update)
+    sys-apps/baselayout -> update-env (env-update)
+    sys-apps/baselayout -> update-etc (etc-update)
+    sys-apps/baselayout -> config-rc (rc-update)
+
+
+Rationale
+=========
+
+Three primary options were presented for the naming scheme:
+
+* The current scheme, \*-config and \*-update. This scheme makes finding a
+  tool difficult, since there is no consistency in the beginning of the name.
+  However, it may be easier for people who already know such a tool exists and
+  remember that its name correlates with the package to be configured (except
+  in the case of many of the \*-update tools).
+
+* A slightly modified version of the proposed scheme, with an abbreviated
+  prefix, shorter than gentoo-\*. For example, the current gcc-config would
+  become gen-config-gcc or g-config-gcc. Although this is shorter to type, the
+  availability of tab completion renders that point largely moot. It may also
+  contribute to confusion through inexact specification of what it is.
+
+* The proposed scheme, gentoo-{config,update}-\*. It provides a streamlined way
+  to discover and use various Gentoo-specific tools, even if one does not
+  remember the exact name. A minor downside is the length of the names, but
+  again this caveat is largely moot because of tab completion.
+
+In an example of another distribution, Red Hat moved to a redhat-config-\*
+scheme within the past couple of years to provide more consistent and
+easier-to-find tools.
+
+After two discussions on gentoo-dev, the majority favored this unified prefix
+for the tools, with a minority in objection, variously favoring one of the
+first two schemes above.
+
+
+Backwards Compatibility
+=======================
+
+To ensure a smooth transition, a wrapper script will be provided in the old
+location. This wrapper will print a warning, sleep 5 seconds, then run the
+tool from its new location. The wrapper script should be provided for the next
+two new ebuilds for the package, whether they are revision or version bumps.
+On the third update, the wrapper script will be removed.
+
+In addition, einfo warnings will be added in the ebuilds for the first three
+new ebuilds. They will run in one more ebuild beyond removal of the wrapper
+script.
+
+
+Reference Implementation
+========================
+
+not yet ..
+
+
+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/.