1 |
Dr Rainer Woitok <rainer.woitok@×××××.com> wrote: |
2 |
> I STRONGLY beg to disagree! The "~amd64" notation is used to ACCEPT a |
3 |
> package even though it is (still) classified as UNSTABLE. |
4 |
|
5 |
This is package-manager terminology which has much less states since |
6 |
a package manager needs no fine distinctions about the reasons of |
7 |
accepting or rejecting a package and which of these reasons are caused |
8 |
by your local configuration. |
9 |
In eix there's several configurations: The default (repository) one |
10 |
and the local one (actually even another one with a local profile |
11 |
override). |
12 |
A lot of states (stable, masked, package-masked, etc) can change between |
13 |
these configurations. You can of course invent a new term for each of the |
14 |
several dozens or more possible combination of states, |
15 |
but it is much simpler and more natural to allow all checks separately |
16 |
and use terms for the individual properties which are similar to that of |
17 |
portage. For the optical output, eix displays less information which |
18 |
are more similar to portage. |
19 |
|
20 |
> If "{!isstable}" isn't equivalent to "{isunstable}", |
21 |
> there's a severe logical problem involved. |
22 |
|
23 |
There would be a severe information problem if there were just a |
24 |
few such states and the natural term "unstable" with the analogous |
25 |
"alienunstable" would have been reserved for a mere negation. |
26 |
|
27 |
> Besides, in my book "was stable" sort of means "is no longer stable" |
28 |
|
29 |
It means it was stable before your local overrides. It may or not be |
30 |
stable after your local overrides. Analogously for alienstable, |
31 |
alienunstable, masked, etc. |