1 |
On Fri, 24 Jan 2014 10:46:06 +0000 |
2 |
"Steven J. Long" <slong@××××××××××××××××××.uk> wrote: |
3 |
|
4 |
> Tom Wijsman wrote: |
5 |
> > "Steven J. Long" wrote: |
6 |
> > > What? Without a stable tree, Gentoo is useless afaic. |
7 |
> > |
8 |
> > It moves us closer to upstream releases, a little more bleeding |
9 |
> > edge; a lot of users and developers run that already, it is found |
10 |
> > to be useful. |
11 |
> |
12 |
> What? More vague. As are many of your philosophical statements in |
13 |
> later and prior mails, so I'll ignore those. |
14 |
|
15 |
It is reality; and thus, without a stable tree, Gentoo is still useful |
16 |
for a lot of users and developers. What is vague about that? |
17 |
|
18 |
> > > I don't think that's what was being proposed, though. The |
19 |
> > > question was really the old complaint about slow architectures; |
20 |
> > > the "-* arch" solution sounds like the most reasonable definition |
21 |
> > > of "dropping" keywords, in the absence of AT communication |
22 |
> > > otherwise. |
23 |
> > |
24 |
> > Dropping keywords and specifying -* are a world apart of each other. |
25 |
> |
26 |
> That's why it's in quotes. |
27 |
|
28 |
Why is there at all if you intend it to be irrelevant to this thread? |
29 |
|
30 |
> > The former means that it is not ready for wide stable or testing |
31 |
> > users, the latter means that it has been tested to not work at all; |
32 |
> > furthermore, we need to explicitly specify which arches in that |
33 |
> > case. |
34 |
> |
35 |
> You're missing the point, again. The question was what does "dropping |
36 |
> keywords" mean, when the maintainer has stabilised a newer version on |
37 |
> the arch/s s/he has available, but feels that slower archs are holding |
38 |
> up that process. |
39 |
|
40 |
Where is that question? |
41 |
|
42 |
> I'm slightly at a loss as to why it's such a big deal to just leave |
43 |
> the old ebuild as-is, given that anyone on a stabled arch should |
44 |
> upgrade automatically. |
45 |
|
46 |
It is when you are running the arch that only has the old version. |
47 |
|
48 |
> But given that the maintainer feels they don't want that old ebuild |
49 |
> around, and that the arch in question has not got round to testing the |
50 |
> new one, for whatever reason (it's their call, after all, as to how |
51 |
> their arch progresses), instead of simply removing that ebuild, or |
52 |
> bumping it to unstable (which makes zero sense), just leave it stable |
53 |
> on the slow arch/s in question, and remove the others. |
54 |
|
55 |
There are situations (security, stability, incompatibility) where |
56 |
keeping it in place becomes a much harder task; at which point, removal |
57 |
is bound to happen. At that point, such action is required. |
58 |
|
59 |
It becomes faster than you think; if you depend on a library, and the |
60 |
compatible range of that library gets wiped by a security bug, your |
61 |
package will suddenly depend on an incompatible newer stabilized |
62 |
version of the library at which point you are up for either a lot of |
63 |
hard work or plain out starting the progress of masking and removing it. |
64 |
|
65 |
> This seems like a rarity, but when it's an issue, people get annoyed |
66 |
> on either side. The solution proposed by the ARM team, |
67 |
|
68 |
Where is this solution? |
69 |
|
70 |
> seems like a simple way round, and indicates clearly to anyone |
71 |
> perusing the ebuild, that a newer version needs stabling on the |
72 |
> "slow" archs. |
73 |
|
74 |
Masking works fine for that too; what this does is make clear to the |
75 |
user that (1) the current stable version has breakage for a specific |
76 |
reason, (2) a newer stable version is not yet available and (3) that the |
77 |
user can choose to keep the breakage or upgrade to an unstable version. |
78 |
|
79 |
> By all means, raise technical objections; just not a philosophical |
80 |
> one. |
81 |
|
82 |
Where are these philosophical objections? |
83 |
|
84 |
-- |
85 |
With kind regards, |
86 |
|
87 |
Tom Wijsman (TomWij) |
88 |
Gentoo Developer |
89 |
|
90 |
E-mail address : TomWij@g.o |
91 |
GPG Public Key : 6D34E57D |
92 |
GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D |