1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
|
---
GLEP: 24
Title: Consistent Gentoo tool naming scheme
Author: Donnie Berkholz <dberkholz@gentoo.org>
Type: Standards Track
Status: Deferred
Version: 1
Created: 2004-03-16
Last-Modified: 2014-01-17
Post-History: 2004-03-17, 2004-10-25
Content-Type: text/x-rst
---
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
https://creativecommons.org/licenses/by-sa/3.0/.
|
GitWeb