| 1 |
On sob, 2017-07-08 at 20:58 +0200, Ulrich Mueller wrote: |
| 2 |
> > > > > > On Sat, 08 Jul 2017, Michał Górny wrote: |
| 3 |
> > On sob, 2017-07-08 at 12:26 +0200, Ulrich Mueller wrote: |
| 4 |
> > > Section "Processing algorithm": |
| 5 |
> > > |
| 6 |
> > > > 2. Check whether the REQUIRED_USE constraint matches restrictions |
| 7 |
> > > > set in #Restrictions on REQUIRED_USE format. If it does not, report |
| 8 |
> > > > a REQUIRED_USE mismatch and abort. |
| 9 |
> > > |
| 10 |
> > > Why is this needed? This case should never occur if the REQUIRED_USE |
| 11 |
> > > syntax doesn't allow it. |
| 12 |
> > The syntax is restricted from the one allowed by the PMS. The |
| 13 |
> > algorithm doesn't cover the weird deep nesting cases. Unless we want |
| 14 |
> > to retroactively change PMS to disallow them as well, the spec needs |
| 15 |
> > to clearly establish the acceptable input for the algorithm |
| 16 |
> > presented. |
| 17 |
> |
| 18 |
> Sorry, but that makes no sense. Why would we introduce automatic |
| 19 |
> solving with the next EAPI, but at the same time not restrict |
| 20 |
> REQUIRED_USE syntax to the one the solver can handle? |
| 21 |
> |
| 22 |
|
| 23 |
Nobody said anything about the next EAPI. The GLEP doesn't say a word |
| 24 |
about introducing it in a future EAPI. |
| 25 |
|
| 26 |
We're adding this as an optional (default off) FEATURE into Portage |
| 27 |
and we'll see how it works. As far as I'm concerned, we can enable it |
| 28 |
for all EAPIs without touching PMS at all. |
| 29 |
|
| 30 |
In fact, the GLEP points out that the PMS does not specifically define |
| 31 |
how PMs are supposed to deal with ensuring that REQUIRED_USE is |
| 32 |
satisfied. Failing with poor error messages is just established |
| 33 |
historical Portage behavior. But if we get good test results |
| 34 |
and majority agreement, I see no reason why we couldn't start enabling |
| 35 |
it by default and eventually relying on it. |
| 36 |
|
| 37 |
After all, it wouldn't be the first non-PMS extension that we accept for |
| 38 |
user convenience yet do not require strictly. |
| 39 |
|
| 40 |
Of course, if you think it should be made obligatory or at least |
| 41 |
accounted for in a future EAPI, I have no problem with that. Ciaran |
| 42 |
might, however. |
| 43 |
|
| 44 |
-- |
| 45 |
Best regards, |
| 46 |
Michał Górny |
Archives