1 |
> It could just be g-config-<package>, or even gconfig-package. |
2 |
|
3 |
Ooh, ooh, I know! How about just "gconf-"? ;) |
4 |
|
5 |
I remember quite some time ago (a year and a half, maybe two years?) of |
6 |
the tools mentioned in this thread that existed, some were of the form |
7 |
update-xyz, the other half were xyz-update - 'modules-update' comes to |
8 |
mind. I understand the pull to want all of the similar tools to be |
9 |
consistent, and using a "config-xyz" or "update-xyz" makes the tools |
10 |
easier to find*. |
11 |
|
12 |
That said, 'xyz-(update|config)' makes more /natural/ sense. If I know |
13 |
that I need to run the module script, I can hit 'module<tab>' and get |
14 |
the right script, or at least a small list of commands. Likewise for |
15 |
most others (though some need a '-' for tab-completion purposes): |
16 |
opengl, etc, gcc, etc. I don't know about you, but normally when I'm |
17 |
using one of these tools I have an express purpose in mind: "change |
18 |
opengl libraries," "change to a different gcc," "see if any etc files |
19 |
have updates," "update my kernel module dependencies", etc. My purposes |
20 |
are generally not "see what configuration I can change today." |
21 |
|
22 |
Unfortunately, I don't have a perfect solution, only suggestions. The |
23 |
idea of "just stick a document somewhere" doesn't cut it - you have the |
24 |
same problem of how to direct people to that document. Add another |
25 |
document pointing to that document, ad infinitum? |
26 |
|
27 |
What about the possibility of some sort of configuration script wrapper? |
28 |
Call it "update", for the sake of simplicity. Then I could run: |
29 |
|
30 |
update gcc |
31 |
update opengl |
32 |
update modules |
33 |
update etc |
34 |
|
35 |
Then various *-config and *-update programs could register themselves |
36 |
somehow, so that "update --help" could list all the things that can be |
37 |
updated on the current system, and could (and should) even include |
38 |
descriptions of what the various commands do. Someone could then write |
39 |
a fairly trivial bash-completion script to allow 'update <tab><tab>' to |
40 |
list all the configuration tools on my system, but good old 'etc-update' |
41 |
would still be there when my first thought is "etc" instead of "update". |
42 |
|
43 |
|
44 |
|
45 |
|
46 |
* (As a side note, to the end of uniformity, opengl-update should |
47 |
probably change to config-opengl (or opengl-config), since it has more |
48 |
in common with the other 'config' scripts than 'update' scripts. |
49 |
'update' should mean "update my system," while 'config' should mean |
50 |
"change something on my system" - where "something" can generally be |
51 |
changed back with the same tool.) |
52 |
|
53 |
-- Jason Rhinelander |
54 |
-- Gossamer Threads, Inc. |
55 |
|
56 |
Chris Smith wrote: |
57 |
> On Tuesday 16 March 2004 20:00, Donnie Berkholz wrote: |
58 |
> |
59 |
>>Finally, I was pondering a gentoo-* prefix on all of these, to ensure an |
60 |
>>even more consistent and easily findable set of tools. That way, |
61 |
>>`gentoo-<tab><tab>` would find every Gentoo tool. |
62 |
> |
63 |
> |
64 |
> SNAP! |
65 |
> |
66 |
> Was just about to suggest the same thing. It doesn't even have to be gentoo |
67 |
> (too long, i remember that redhat-config-network was a crappy name to type). |
68 |
> It could just be g-config-<package>, or even gconfig-package. |
69 |
> |
70 |
> Although gentoo-* has the advantage of just hitting gentoo-<tab> and getting |
71 |
> the list of stuff. Whereas a "g" would trawl up all the gnome crap. |
72 |
> |
73 |
> Cheers, |
74 |
> Chris. |
75 |
> |
76 |
> -- |
77 |
> gentoo-dev@g.o mailing list |
78 |
> |
79 |
> |
80 |
|
81 |
-- |
82 |
gentoo-dev@g.o mailing list |