1 |
On nie, 2017-07-09 at 09:22 +0200, Ulrich Mueller wrote: |
2 |
> > > > > > On Sat, 08 Jul 2017, Michał Górny wrote: |
3 |
> > Nobody said anything about the next EAPI. The GLEP doesn't say a |
4 |
> > word about introducing it in a future EAPI. |
5 |
> > We're adding this as an optional (default off) FEATURE into Portage |
6 |
> > and we'll see how it works. As far as I'm concerned, we can enable |
7 |
> > it for all EAPIs without touching PMS at all. |
8 |
> |
9 |
> Not sure if this is a good idea. First, there is the issue that we |
10 |
> would have different syntax for REQUIRED_USE, a looser one defined by |
11 |
> PMS and a stricter one defined by your GLEP, which can cause |
12 |
> confusion. |
13 |
> |
14 |
> Second, and more important, introduction of an automatic solver would |
15 |
> inevitably lead to proliferation of REQUIRED_USE in the tree. However, |
16 |
> nothing would guarantee that the package manager on the user's side is |
17 |
> capable of solving the constraints automatically. The result would be |
18 |
> more emerge failures and asking for more micro-management of flags by |
19 |
> users. |
20 |
|
21 |
Think of dynamic deps. We were able to eventually contain them, |
22 |
and teach developers not to account for them even though they are still |
23 |
enabled by default, I think. |
24 |
|
25 |
I don't see why optional autosolving of REQUIRED_USE could not be |
26 |
contained by a policy as well. Of course, there will be some people who |
27 |
will violate it but it's not something that doesn't happen anyway right |
28 |
now. |
29 |
|
30 |
In fact, consider that people hit REQUIRED_USE conflicts today and have |
31 |
no help against them, adding the autosolver will certainly reduce |
32 |
the overall 'conflict hit rate' of our users, even if more conflicts are |
33 |
introduced by the developers not following the policy. |
34 |
|
35 |
See all the RequiredUseDefaults reports in [1]. And that's purely for |
36 |
the profile-set defaults, i.e. packages that fail to emerge out-of-the- |
37 |
box. |
38 |
|
39 |
> > In fact, the GLEP points out that the PMS does not specifically |
40 |
> > define how PMs are supposed to deal with ensuring that REQUIRED_USE |
41 |
> > is satisfied. Failing with poor error messages is just established |
42 |
> > historical Portage behavior. But if we get good test results and |
43 |
> > majority agreement, I see no reason why we couldn't start enabling |
44 |
> > it by default and eventually relying on it. |
45 |
> > After all, it wouldn't be the first non-PMS extension that we accept |
46 |
> > for user convenience yet do not require strictly. |
47 |
> |
48 |
> See above. I fear it would cause pain for users whose PM doesn't |
49 |
> implement the feature. |
50 |
|
51 |
So do broken executables for PMs that do not preserve-libs. This is not |
52 |
something we can cover 100%. We can aim to make it work automatically |
53 |
for the most, and be solvable for the rest. |
54 |
|
55 |
> > Of course, if you think it should be made obligatory or at least |
56 |
> > accounted for in a future EAPI, I have no problem with that. Ciaran |
57 |
> > might, however. |
58 |
> |
59 |
> That is exactly what EAPI was invented for. Ebuild authors can only |
60 |
> rely on package manager support on users' side if the feature is |
61 |
> introduced with a new EAPI. Leaving the policy specified in [1] in |
62 |
> place forever is no good alternative, because then the full potential |
63 |
> of the automatic solver could not be exploited in ebuilds. (Also, how |
64 |
> would we enforce the devmanual policy?) |
65 |
|
66 |
Are you suggesting that we introduce half-tested feature in EAPI 7, then |
67 |
spend a few years figuring out that it doesn't work as expected? Because |
68 |
I don't see how we get it tested properly without having users actually |
69 |
test it and report the results. |
70 |
|
71 |
Or are you suggesting that we go through those 10000 ebuilds and test |
72 |
every flag combination by hand? And then, we figure out that with |
73 |
the new feature the developers start writing different REQUIRED_USE |
74 |
constraints and find bugs. |
75 |
|
76 |
[1]:https://qa-reports.gentoo.org/output/gentoo-ci/output.html |
77 |
|
78 |
-- |
79 |
Best regards, |
80 |
Michał Górny |