Gentoo Archives: gentoo-dev

From: "William L. Thomson Jr." <wlt-ml@××××××.com>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] Reverse use of Python/Ruby versions
Date: Mon, 10 Apr 2017 22:35:25
Message-Id: assp.0273d764f3.20170410183513.2f8af4e5@o-sinc.com
In Reply to: Re: [gentoo-dev] Reverse use of Python/Ruby versions by Kent Fredric
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.

Replies

Subject Author
Re: [gentoo-dev] Reverse use of Python/Ruby versions Kent Fredric <kentnl@g.o>