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 |