summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorMichał Górny <mgorny@gentoo.org>2017-07-07 20:35:00 +0000
committerMichał Górny <mgorny@gentoo.org>2017-07-07 20:35:00 +0000
commit68442dfedafb3998bd516669304ca0f328edb4ce (patch)
tree3396c543d51a9132b526992b14cd00c12d5e011f
parent/* QA checks to verify REQUIRED_USE solutions */ mention the indirect implica... (diff)
downloadglep-68442dfedafb3998bd516669304ca0f328edb4ce.tar.gz
glep-68442dfedafb3998bd516669304ca0f328edb4ce.tar.bz2
glep-68442dfedafb3998bd516669304ca0f328edb4ce.zip
/* QA checks/verification */ immutability check
-rw-r--r--GLEP:73.mw21
1 files changed, 21 insertions, 0 deletions
diff --git a/GLEP:73.mw b/GLEP:73.mw
index 62efd52..4c12757 100644
--- a/GLEP:73.mw
+++ b/GLEP:73.mw
@@ -483,6 +483,27 @@ The effective algorithm selected is somehow a simplified derivation of the above
Even with the additional logic needed to prevent some of the false positives the algorithm is still fast enough to serve its purpose. While it is not perfect, it has been tested on all real cases of REQUIRED_USE from Gentoo and verified not to cause any issues.
+====Verification of enforcing immutable flags====
+The first of the checks is meant to ensure that under no circumstances the constraint will attempt to toggle flags that are immutable, that is whose values are established through use.mask / use.force files. This concept is not only important for the scope of this GLEP but it also ensures that the constraints could be satisfied at all.
+
+The generic idea is that the following constraint:
+
+ a? ( b )
+
+combined with use.mask on ''b'' will cause an error because if the user enables ''a'', then ''b'' is required but it can not be enabled. Likewise, the following:
+
+ a? ( !b )
+
+with ''b'' use.forced will cause an error since ''b'' can not be disabled.
+
+Those constraints would be acceptable if ''a'' were masked as well, as to prevent the condition from ever being true. This is both the reason for the rule on the condition of flattened constraint, and the correct solution for the issue.
+
+It should be noted that the check is done separately for every flattened constraint, and does not consider the implications of other constraints. That is, given the following example constraint:
+
+ !a? ( !b ) b? ( c )
+
+with both ''a'' and ''c'' masked, the check will still consider the REQUIRED_USE erroneous even though ''b'' could not ever be true. However, this is not realistically considered an issue and can be solved via masking ''b'' as well. It will also improve the clarity of the USE flags and avoid giving a false sense that ''b'' could be enabled.
+
==Backwards compatibility==
===Compliance with the PMS===