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