Gentoo Archives: gentoo-dev

From: james <garftd@×××××××.net>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] REQUIRED_USE, global USE flags, user-friendliness...
Date: Fri, 27 Jan 2017 19:57:15
Message-Id: aabdeb6f-3fa1-7d99-09fe-d4ecd39ef42c@verizon.net
In Reply to: [gentoo-dev] REQUIRED_USE, global USE flags, user-friendliness... by Michael Orlitzky
1 On 01/27/2017 12:25 PM, Michael Orlitzky wrote:
2 > Forked from the gdbm/berkdb thread, wall of text ensues...
3 >
4 >
5 > On 01/27/2017 03:32 AM, Fabian Groffen wrote:
6 >>
7 >> You mention REQUIRED_USE should be used sparingly, I think I see your
8 >> reasoning, but if so, then why did we add it in the first place?
9 >
10 > There are a few conflicting interests at play. Before REQUIRED_USE, we
11 > would have a bunch of checks in pkg_pretend() to test if the user's
12 > configuration was invalid. If it was, we could output a nice explanation
13 > and tell him to try again. But, bash code in pkg_pretend can't be
14 > understood by the package manager, and requires execution to determine
15 > if a package can be installed. So we got REQUIRED_USE, which fixes those
16 > problems, and introduces a new one: no one knows WTF to do when portage
17 > outputs a REQUIRED_USE error. Now you get what looks like a core dump of
18 > the dependency graph instead of "this package only uses one database, so
19 > pick either mysql or sqlite."
20 >
21 > Both approaches have another problem: USE flag constraints on packages
22 > simply don't work with global USE flags. Global USE flags don't work
23 > that well to begin with, since the same flag means different things to
24 > each package (and the fact that they're global means "enable foo" is all
25 > we get for documentation). Regardless, when you have 100 flags enabled
26 > globally and start installing thousands of packages with USE
27 > constraints, you're eventually going to get to a point where everything
28 > has conflicting requirements and you need to switch to package.use to
29 > sort it all out.
30 >
31 > Both pkg_pretend and REQUIRED_USE have that problem and try to solve it
32 > in different ways. If you don't care about machine-readability, then in
33 > pkg_pretend you could try to choose "the best" of two conflicting flags
34 > and just silently go with it. There are a lot of problems with that,
35 > like what happens if you need to add a conditional dependency on those
36 > flags (you can't change DEPEND in pkg_pretend). With REQUIRED_USE, you
37 > instead need to set IUSE defaults to get it to do something without user
38 > interaction, but the tricks that you can do with IUSE don't solve every
39 > REQUIRED_USE conflict. In the harder cases, you can try to figure out
40 > what to do on behalf of the user in the ebuild, but then you're right
41 > back to the same set of problems that you had with pkg_pretend, because
42 > the decision is being made in code and not in metadata/flags.
43 >
44 > I think a slow migration away from global USE flags is the only way out
45 > of the jam. We get better USE flag docs for free, and no REQUIRED_USE
46 > conflicts that the user didn't cause himself. We could probably also get
47 > rid of a lot of IUSE defaults that serve only to undo various profile
48 > defaults. It would be annoying at first, but once a few critical profile
49 > defaults are moved into package.use, better.
50
51 Exactly:: simplify the flags, profiles and associated constructs down to
52 the bare bones. Even embedded (arm/mips/etc) builds could benefit from a
53 really minimized gentoo as a starting point. Freedom to build and fork
54 Gentoo, per GLEP 70 is a wonderful idea, whose time has arrived. That
55 would set the stage for quickly building highly specific gentoo installs
56 (VMs, Containers, Clusters or unikernel); all via a 'recipe' from the
57 minimal core-sed, which could then take a variety of forms, such as
58 bare-metal builds vi IPMI, ipxe, or more traditional formularies like
59 chef, puppet, ansible as well as a myriad of other possibilities.
60
61
62 All of the traditional gentoo installs, such as the handbook, would
63 benefit from simplification and the natural clarity that simplification
64 brings. Builds of things like simple standard gentoo-cluster-CI. Nothing
65 would preclude the adventuresome from building up
66 a traditional, highly customized install, for a specific needs such as
67 currently is the (handbook) practice. But additional gentoo installs
68 that are quick, streamlined and soot a specific itch.
69
70
71 That way a user, a proxy-dev or a dev could work on any and every aspect
72 of gentoo, perfectly isolated from other devs with a select group of
73 testers. Each team could maintain their build formulary very easily, and
74 others could provide the bugzilla feedback on that particular
75 fork/custom/project. Those bugs would be assign to the project
76 fork-team. Gentoo-proper would benefit being able to 'reap' the
77 benefits of a streamlined develop, deploy, test, refine, stabilize
78 efforts; and folks can each have their own fiefdom, whilst still sharing
79 gentoo-proper as we currently do. And bgo would be a default place to
80 seach out gentoo specific issue, both on gentoo-proper and these glep-70
81 projects. Of a separate bugs-engine for these projects
82 that is a companion to bgo, but separated, if that is better?
83
84
85 There are at least a half dozen folks that have done this, their own
86 gentoo-derived-distro, many were mainstream devs at some point. Why not
87 streamline and optimize that systems, to the benefit of gentoo-proper?
88 Gentoo proper dev testing could occur either before a project (glep 70)
89 fork, or afterwards as the benefits are tested and vetted for
90 introduction back into gentoo-proper. A polished
91 gentoo-cluster-CI semantic makes all of this immensely easier, imho.
92
93
94 Common ground between gentoo and it's offspring distros, could become a
95 very powerful platform, unique among distros, imho. Flag minimization
96 and freedom is a core need shared by all forms of gentoo, imho.
97
98
99 hth,
100 James

Replies

Subject Author
Re: [gentoo-dev] REQUIRED_USE, global USE flags, user-friendliness... Walter Dnes <waltdnes@××××××××.org>