>>>>> 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. Also, I believe that with an automatic solver, we would want to change the policy defined in the devmanual which says that REQUIRED_USE should be used sparingly [1]? When would we do this, if the feature isn't connected to an EAPI? After a long enough waiting period? Welcome back to pre-EAPI-0 times. > 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. > 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?) Ulrich [1] https://devmanual.gentoo.org/general-concepts/use-flags/index.html#conflicting-use-flags
pgpAaknfTFtPd.pgp
Description: PGP signature
