1 |
Martin, |
2 |
|
3 |
On Sunday, 2020-05-03 15:55:59 -0000, you wrote: |
4 |
|
5 |
> ... |
6 |
> > I STRONGLY beg to disagree! The "~amd64" notation is used to ACCEPT a |
7 |
> > package even though it is (still) classified as UNSTABLE. |
8 |
> |
9 |
> This is package-manager terminology which has much less states since |
10 |
> a package manager needs no fine distinctions about the reasons of |
11 |
> accepting or rejecting a package and which of these reasons are caused |
12 |
> by your local configuration. |
13 |
|
14 |
No it's USER terminology. It's what users are confronted with when they |
15 |
set-up their Portage configuration and when they deal with commands like |
16 |
"emerge", "equery", and ilk. In your mail dating 2020-04-24 17:32:09 |
17 |
-0000 even you said "Maybe you run an unstable system, that is ACCEPT_ |
18 |
KEYWORDS='~amd64'?" because you knew that on an "unstable" system (user |
19 |
terminology) property "{isstable}" ("eix" developers' terminology) will |
20 |
always return True. |
21 |
|
22 |
But if I learned anything about software development in my former life, |
23 |
it's that everything a user or administrator passes as option or argum- |
24 |
ent to some command or inserts into some configuration file has to be |
25 |
described in the manuals using USER terminology. |
26 |
|
27 |
Brilliant programmers may write brilliant software, but if they write |
28 |
sloppy documentation or use counterintuitive terminology therein, only a |
29 |
few stubborn people will use this software in a few special cases they |
30 |
have struggled to understand, and all the brilliance goes mainly unnot- |
31 |
iced and is thus more or less wasted. No software can be better than |
32 |
its documentation! |
33 |
|
34 |
> ... |
35 |
> There would be a severe information problem if there were just a |
36 |
> few such states and the natural term "unstable" with the analogous |
37 |
> "alienunstable" would have been reserved for a mere negation. |
38 |
|
39 |
It's not a matter of the number of states but a matter of choosing in- |
40 |
tuitive names for them. Simply due to USER EXPECTATION the term "un- |
41 |
stable" HAS to be the opposite of "isstable" (and thus is unnecessary |
42 |
because there is also "!isstable"). And if finer granularity is needed, |
43 |
more (but carefully chosen) property names have to be introduced. But |
44 |
if every state introduced isn't clearly and precisely defined in some |
45 |
manual, it's not too surprising that only few people manage to use the |
46 |
software. |
47 |
|
48 |
Sincerely, |
49 |
Rainer |