1 |
On 06/02/2016 02:55 PM, Rich Freeman wrote: |
2 |
> On Thu, Jun 2, 2016 at 5:27 PM, Daniel Campbell <zlg@g.o> wrote: |
3 |
>> To play devil's advocate, can we get a citation on "users don't want to |
4 |
>> care"? Which users? Does Gentoo have a lot of users who don't care, or |
5 |
>> does it attract a more passionate audience that enjoys the control that |
6 |
>> comes with being source-based? I'm inclined to believe the latter, but |
7 |
>> I'm ready to be wrong. |
8 |
>> |
9 |
> |
10 |
> I'm willing to believe we have a lot of users who love micromanaging |
11 |
> USE flags. The day Gentoo requires this sort of behavior to work |
12 |
> correctly is the day I won't be a user... :) |
13 |
> |
14 |
> Gentoo SHOULD give users choices. It should also pick reasonable |
15 |
> defaults when users opt not to specify a choice. |
16 |
I agree. Sane defaults are what make system maintenance easy. |
17 |
|
18 |
> |
19 |
> Obviously if a user just wants Ubuntu or Arch they should just install |
20 |
> Ubuntu or Arch. However, I think a common use case is going to be a |
21 |
> user wants very fine-grained control over a particular aspect of their |
22 |
> system, but they're not going to care about the rest. Maybe a user |
23 |
> does a lot of development in a particular language and they want |
24 |
> fine-grained control over how their compiler/interpreter/etc works, |
25 |
> but that doesn't mean that when they fire up a browser to check |
26 |
> stackexchange that they want to tweak every setting. Maybe somebody |
27 |
> has a server used for media transcoding and they want to tweak all the |
28 |
> ffmpeg/libav build options, but otherwise want a distro that just |
29 |
> works as far as ssh/openrc/systemd and so on goes. |
30 |
> |
31 |
> It would be one thing if we had to sacrifice the super-OCD users to |
32 |
> cater to the non-OCD users. However, I don't really see a reason why |
33 |
> we can't service both. This proposal works for either set of users. |
34 |
> If a package doesn't give fine-grained control over libraries then the |
35 |
> OCD users aren't really losing anything they had before. If it does |
36 |
> then USE=+gui gets the users who don't care their gui, and it still |
37 |
> lets the people who want to tweak qt/gtk/etc the ability to do so. |
38 |
> |
39 |
Well, that's the incoming problem when we accept USE="gui". I'm in favor |
40 |
of the change in spirit, because who doesn't want a Gentoo that needs |
41 |
less babysitting? However, the devil is in the details with what this |
42 |
change leads to. Let's say we push the gui flag anyway. It is a good |
43 |
idea, after all. Now how do we, as developers, deal with the |
44 |
intricacies? There's adding +foo to IUSE, there's REQUIRED_USE, the |
45 |
proposed USE_EXPAND (and a strange syntax added to clarify preference), |
46 |
and pkg_pretend. All of these are possible solutions but *which* |
47 |
solution most definitely will affect the "super-OCD" users. Ideally, we |
48 |
should only need to tell these users where the new change goes, e.g. |
49 |
"Don't set it in make.conf anymore, use p.use or p.env" or some other |
50 |
thing. We need to make sure that there's only _one_ step needed for each |
51 |
group. The "everyman" user can add USE="gui" and be done with it. The |
52 |
picky user will need to set their preference in some other way, but it |
53 |
should only be in one place instead of, say, two or three. |
54 |
|
55 |
Let's use a concrete example here: x11-misc/spacefm. For another, |
56 |
different example, net-p2p/transmission. The former supports two |
57 |
versions of GTK, the latter accepts three (or more?) different toolkits, |
58 |
in addition to ncurses which _might_ be considered a GUI to some. (It |
59 |
seems that GTK2 support is no longer accepted; is that upstream decision |
60 |
or maintainer's? But I digress...) |
61 |
|
62 |
Currently, setting that preference ("Screw qt4 I want qt5" or "Screw |
63 |
GTK3 I want 2!") usually requires either a global make.conf setup (which |
64 |
some of us are against due to it meaning different things in different |
65 |
packages), or adding a p.use entry for every piece of software that one |
66 |
has an opinion on. Sometimes REQUIRED_USE necessitates negating the |
67 |
other options. (I regret that spacefm does this, but I'm not changing it |
68 |
until we have a real solution) |
69 |
|
70 |
If the USE_EXPAND is used, we get the GUI variable in make.conf that can |
71 |
then be used to hint ebuilds as to what the user finds acceptable. If |
72 |
they love Qt5 on everything except that one program, then -gui_qt5 in |
73 |
p.use for that one program would work, and make sense. Choice of toolkit |
74 |
is usually a global decision, so the GUI USE sounds great, until we get |
75 |
conflicts. We then have to figure out what the preferred way to resolve |
76 |
that conflict. For example, let's say someone adds gtk2 and qt5 to their |
77 |
GUI in make.conf. A particular ebuild supports both. Do we hack the |
78 |
build system to make two versions of the program? Do we perform the same |
79 |
option that they'd get if it was just USE="gui"? What will our DEPENDS |
80 |
look like after enacting this change? We need an honest answer about |
81 |
this, even if it's just "maintainer discretion" and/or "use pkg_pretend". |
82 |
|
83 |
In short, I'm in support of this _idea_, but until we have some sort of |
84 |
suggestion on how maintainers should implement this for their users, |
85 |
we're going to get inconsistency between maintainers and the problem |
86 |
will remain. |
87 |
|
88 |
We need some sort of guide or document telling us what the new change is |
89 |
(USE="gui"), how picky users will be accommodated, and how maintainers |
90 |
can make it happen. Maybe even a repoman check or something, if that's |
91 |
feasible. From what I gather, this discussion has gone on for over a |
92 |
decade. If we can figure out the implementation and it covers the same |
93 |
use cases that are possible now, I'll even help write the wiki page. I |
94 |
just need to know *what* should be done, so I can clean up my ebuilds |
95 |
and help others clean up theirs. |
96 |
|
97 |
I understand this hasn't been decided yet, and Mart (if that's okay; |
98 |
otherwise leio) is working on his proposal for a solution. I just want |
99 |
to clarify that this decision is not just a single global USE flag and |
100 |
will require instructions. Without instructions or guidelines/a |
101 |
checklist, maintainers won't know how to adhere to this suggestion and |
102 |
they'll throw their hands up. It's unrealistic to expect QA to do all |
103 |
that work, too. |
104 |
|
105 |
(Sorry if I repeated myself; I figured rephrasing may assist in my |
106 |
expression and others' understanding) |
107 |
-- |
108 |
Daniel Campbell - Gentoo Developer |
109 |
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net |
110 |
fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6 |