>>>>> On Sun, 09 Jul 2017, Michał Górny wrote: > On nie, 2017-07-09 at 09:22 +0200, Ulrich Mueller wrote: >> 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. Then can you please confirm that the policy outlined in https://devmanual.gentoo.org/general-concepts/use-flags/index.html#conflicting-use-flags can stay in place indefinitely, and that your GLEP doesn't intend to change it? > Of course, there will be some people who will violate it but it's > not something that doesn't happen anyway right now. A policy that isn't enforced is useless. > 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? No, I am suggesting that we introduce a new package manager feature in a well defined way, so that ebuild authors can rely on it. We have a mechanism for that, and I don't see a good reason not to follow it. > Because I don't see how we get it tested properly without having > users actually test it and report the results. It shouldn't be necessary for the spec to specify all details of the algorithm. It should catch the basics though in the next EAPI, like leftmost preferred, banning empty groups, and banning USE conditionals inside groups. Ulrich
pgpd3g7YRU5Zz.pgp
Description: PGP signature
