1 |
On Fri, 27 Jan 2017 15:51:27 -0500 |
2 |
NP-Hardass <NP-Hardass@g.o> wrote: |
3 |
|
4 |
> On 01/27/2017 12:25 PM, Michael Orlitzky wrote: |
5 |
> > Forked from the gdbm/berkdb thread, wall of text ensues... |
6 |
> > |
7 |
> > |
8 |
> > On 01/27/2017 03:32 AM, Fabian Groffen wrote: |
9 |
> >> |
10 |
> >> You mention REQUIRED_USE should be used sparingly, I think I see |
11 |
> >> your reasoning, but if so, then why did we add it in the first |
12 |
> >> place? |
13 |
> > |
14 |
> > There are a few conflicting interests at play. Before REQUIRED_USE, |
15 |
> > we would have a bunch of checks in pkg_pretend() to test if the |
16 |
> > user's configuration was invalid. If it was, we could output a nice |
17 |
> > explanation and tell him to try again. But, bash code in |
18 |
> > pkg_pretend can't be understood by the package manager, and |
19 |
> > requires execution to determine if a package can be installed. So |
20 |
> > we got REQUIRED_USE, which fixes those problems, and introduces a |
21 |
> > new one: no one knows WTF to do when portage outputs a REQUIRED_USE |
22 |
> > error. Now you get what looks like a core dump of the dependency |
23 |
> > graph instead of "this package only uses one database, so pick |
24 |
> > either mysql or sqlite." |
25 |
> > |
26 |
> > Both approaches have another problem: USE flag constraints on |
27 |
> > packages simply don't work with global USE flags. Global USE flags |
28 |
> > don't work that well to begin with, since the same flag means |
29 |
> > different things to each package (and the fact that they're global |
30 |
> > means "enable foo" is all we get for documentation). Regardless, |
31 |
> > when you have 100 flags enabled globally and start installing |
32 |
> > thousands of packages with USE constraints, you're eventually going |
33 |
> > to get to a point where everything has conflicting requirements and |
34 |
> > you need to switch to package.use to sort it all out. |
35 |
> > |
36 |
> > Both pkg_pretend and REQUIRED_USE have that problem and try to |
37 |
> > solve it in different ways. If you don't care about |
38 |
> > machine-readability, then in pkg_pretend you could try to choose |
39 |
> > "the best" of two conflicting flags and just silently go with it. |
40 |
> > There are a lot of problems with that, like what happens if you |
41 |
> > need to add a conditional dependency on those flags (you can't |
42 |
> > change DEPEND in pkg_pretend). With REQUIRED_USE, you instead need |
43 |
> > to set IUSE defaults to get it to do something without user |
44 |
> > interaction, but the tricks that you can do with IUSE don't solve |
45 |
> > every REQUIRED_USE conflict. In the harder cases, you can try to |
46 |
> > figure out what to do on behalf of the user in the ebuild, but then |
47 |
> > you're right back to the same set of problems that you had with |
48 |
> > pkg_pretend, because the decision is being made in code and not in |
49 |
> > metadata/flags. |
50 |
> > |
51 |
> > I think a slow migration away from global USE flags is the only way |
52 |
> > out of the jam. We get better USE flag docs for free, and no |
53 |
> > REQUIRED_USE conflicts that the user didn't cause himself. We could |
54 |
> > probably also get rid of a lot of IUSE defaults that serve only to |
55 |
> > undo various profile defaults. It would be annoying at first, but |
56 |
> > once a few critical profile defaults are moved into package.use, |
57 |
> > better. |
58 |
> |
59 |
> I might be wrong, but my suspicion is that those that advocate for |
60 |
> pkg_pretend over REQUIRED_USE tend to do so because of the blocking |
61 |
> nature of REQUIRED_USE's current implementation rather than the |
62 |
> construct of describing USE flag inter-dependencies itself. |
63 |
> |
64 |
> So, personally, I think that we should be discussing ways of adding |
65 |
> interactivity to the package manager for resolution of REQUIRED_USE |
66 |
> conflicts rather than discussing ways to work around or remove it. |
67 |
> It's a good construct, we should take advantage of it, and work to |
68 |
> make it more user friendly. |
69 |
> |
70 |
> My initial feeling is having flags, one for interactive handling, one |
71 |
> for current behavior. Interactive has two modes, like --autounmask |
72 |
> and --autounmask-write (and could even reuse these if possible), |
73 |
> which does something similar to how Debian's apt handles dependency |
74 |
> conflicts by calculating the alternatives and prompting the user to |
75 |
> select a numbered option. So the autounmask equivalent displays the |
76 |
> changes to the config files and the autounmask-write equivalent |
77 |
> writes them to the appropriate config files. This is just a general |
78 |
> idea that I just came up with right now, so I haven't put too much |
79 |
> thought into it. It is mostly meant to get solutions for interactive |
80 |
> handling discussed on the ML. |
81 |
|
82 |
If I may add a user opinion. I agree with you but I would choose |
83 |
different solution for user-friendliness. Instead of _adding_ |
84 |
interactivity to PM I would _remove_ it. So if there would be multiple |
85 |
choices the user would not be prompted, but some default option would be |
86 |
selected by PM. To the user, such behaviour would be similar to |
87 |
current handling of virtuals - if a package depends on a virtual the |
88 |
user is not prompted to make a choice but the default is selected |
89 |
instead. |
90 |
|
91 |
Some of the USE settings levels would have to be overridable by PM in |
92 |
order to achieve this - most likely it would be global and default |
93 |
ones and perhaps also the ones in make.conf. The override of a |
94 |
particular USE flag would be valid only while there is a need. |
95 |
|
96 |
Technically, PM would not update any configuration files (in /etc/) in |
97 |
this process. The required information would be stored in PM's |
98 |
internal structures (/var/db/pkg?). |
99 |
|
100 |
In general, I consider user friendly behaviour if emerge does not ask me |
101 |
anything during the update/install process. It however should clearly |
102 |
show me what it is going to do (with --verbose enabled). |
103 |
|
104 |
Best regards, |
105 |
Robert |
106 |
|
107 |
|
108 |
-- |
109 |
Róbert Čerňanský |
110 |
E-mail: openhs@×××××××××.com |
111 |
Jabber: hs@××××××.sk |