1 |
On Tue, 11 Apr 2017 10:09:51 +1200 |
2 |
Kent Fredric <kentnl@g.o> wrote: |
3 |
|
4 |
> On Mon, 10 Apr 2017 16:01:55 -0400 |
5 |
> |
6 |
> You're running ~arch, I recall. |
7 |
|
8 |
Yes but most servers run stable. Though they have some ~arch packages. |
9 |
I may move to fully ~arch. I think stabilization on Gentoo is a |
10 |
misnomer. Usually newer stuff tends to be more stable than older with |
11 |
bugs etc. Some upstreams have release schedules that would ensure |
12 |
the package be outdated in Gentoo stable. |
13 |
|
14 |
My development env is all ~arch. That way I can be forewarned. Though I |
15 |
have allot of the same issues in stable systems. Why I do not really |
16 |
consider them to be such. |
17 |
|
18 |
> This means adding new is slow for arch users. |
19 |
|
20 |
Same for Java, and slower to get a JDK actually stabilized. Even worse |
21 |
with the from source java requirement. Since from source will most |
22 |
always lag binary from Oracle. |
23 |
|
24 |
> But it also means there's a clear line in the sand when something can |
25 |
> be stabilized. |
26 |
|
27 |
We went the route of masking and unmasking. |
28 |
|
29 |
> ~arch is not great here, but that's why arch exists: ~arch is the |
30 |
> buffer zone where the horrors are supposed to be exorcised. |
31 |
|
32 |
In the days I came to Gentoo. You were not allowed to break stuff in |
33 |
~arch. Even though it did occur. It was very rare. If it was broken, it |
34 |
needed to be masked for testing till it can be safely unmasked. |
35 |
|
36 |
> But as annoying as "oh, doesn't support new target yet" is, its much |
37 |
> less annoying than "oh, it says it supports the new target, but |
38 |
> actually doesn't, and now I have portage screaming at me to toggle |
39 |
> use flags while I report this, and then some poor gentoo developer is |
40 |
> going to have to recursively find all the broken dependents and |
41 |
> remove their use flags" |
42 |
|
43 |
I had the issue where a month ago I swapped everything to Ruby 2.4. |
44 |
Then something changed, in the deps. Something wanted Ruby 2.3. as of |
45 |
April 3rd. My build servers last build was on the 2nd. Then I spent |
46 |
several hours dealing with a problem that did not exist a few week back |
47 |
or on April 2nd. |
48 |
|
49 |
Since more Ruby packages are getting ruby24. |
50 |
|
51 |
|
52 |
> Its the same hell of keywording. |
53 |
> |
54 |
> Its much easier to *add* new keywords/useflags as repoman can |
55 |
> trivially tell you if you made any mistakes, because repoman can only |
56 |
> see how your package is, and how your dependencies are. |
57 |
|
58 |
There were other things that were better on removal. paludis had some |
59 |
useful features. But that has changed so much last I tried to install it |
60 |
was a mess. Seemed to want to deviate from how portage was setup. More |
61 |
like one or the other not both. Both would require work. I was not very |
62 |
committed just playing and experimenting. Trying to get at the |
63 |
information I recall from using it in the past. |
64 |
|
65 |
It used to give you an idea on deps so if you were to drop something |
66 |
the impact. I maybe wrong, but I recall something along those lines. I |
67 |
imagine it still has that ability. |
68 |
|
69 |
> *removing* useflags/keywords is much messier, because repoman can't |
70 |
> tell you what you broke. |
71 |
|
72 |
No but I believe other tools can. |
73 |
|
74 |
> Not without doing a full tree check, which takes 30 minutes+ on my |
75 |
> hardware. |
76 |
|
77 |
Have you worked with paludis? If you can get that setup it should give |
78 |
you more useful output in less time. Ciaran would know there, and maybe |
79 |
some others. |
80 |
|
81 |
> Hence, that's the sort of problem I'm more inclined to throw grep at |
82 |
> and then run it through an automated test PR to make sure I didn't |
83 |
> break anything if I was really concerned. |
84 |
|
85 |
Check out paludis |
86 |
|
87 |
-- |
88 |
William L. Thomson Jr. |