On sob, 2017-07-08 at 20:58 +0200, Ulrich Mueller wrote: > > > > > > On Sat, 08 Jul 2017, Michał Górny wrote: > > On sob, 2017-07-08 at 12:26 +0200, Ulrich Mueller wrote: > > > Section "Processing algorithm": > > > > > > > 2. Check whether the REQUIRED_USE constraint matches restrictions > > > > set in #Restrictions on REQUIRED_USE format. If it does not, report > > > > a REQUIRED_USE mismatch and abort. > > > > > > Why is this needed? This case should never occur if the REQUIRED_USE > > > syntax doesn't allow it. > > The syntax is restricted from the one allowed by the PMS. The > > algorithm doesn't cover the weird deep nesting cases. Unless we want > > to retroactively change PMS to disallow them as well, the spec needs > > to clearly establish the acceptable input for the algorithm > > presented. > > Sorry, but that makes no sense. Why would we introduce automatic > solving with the next EAPI, but at the same time not restrict > REQUIRED_USE syntax to the one the solver can handle? >
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. 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. 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. -- Best regards, Michał Górny
signature.asc
Description: This is a digitally signed message part
