[gentoo-pms] [PATCH] RFC: try to rework and expand RESTRICT rules to be more accurate.

[Brian Harring]

The wording in use here I don't think is yet ready for primetime; the intent
is to clarify that if the RESTRICT is contradicting PMS runtime, then ebuilds
cannot rely upon it (since that scenario essentially means it forces all other
PMs to match that behaviour, regardless of PMS).

If the RESTRICT is turning off a feature of a PM that doesn't contradict PMS
runtime, this should be acceptable for the ebuild to rely upon- basically it
doesn't force other PMs to go match that feature, it shifts the pain point to
the PM that has the feature working to try and maximize compatibility, and
coopt ebuild devs to add the restrict; this effectively is how new
features/RESTRICTS come about.

The purpose of this is that ultimately, I intend RESTRICT=fakeroot and
RESTRICT=unshare to be added; that said my fakeroot implementation is busted
and needs updating, and re-validating that it's sane/viable before it's
encoded into the spec.  For RESTRICT=unshare, nobody has implemented this
feature yet; not expecting any major issues (it's a simple change), but
the lack of any real world field testing, again, makes me hesitant to
immediately add it into the spec.

Thus the intent of changing the RESTRICT wording to match the actual real world
requirements; in the process allowing for those features, and others like it,
to be developed/tested/expanded upon, and ultimately folded into PMS once
proven sane.
---
 dependencies.tex | 19 ++++++++++++++++++-
 1 file changed, 18 insertions(+), 1 deletion(-)

diff --git a/dependencies.tex b/dependencies.tex
index 47c0261..bc36df7 100644
--- a/dependencies.tex
+++ b/dependencies.tex
@@ -370,7 +370,24 @@ The following tokens are permitted inside \t{RESTRICT}:
 \item[sandbox] The \t{sandbox} tool must not be used when building the package.
 \end{description}
 
-Package managers may recognise other tokens, but ebuilds may not rely upon them being supported.
+Package managers may recognise other tokens, but ebuilds may not rely upon them being supported
+if the restrict's notion effectively removes something from the standard ebuild environment or runtime.
+Using sandbox as an example, since it's considered a standard part of our runtime environment, if
+RESTRICT=sandbox wasn't already whitelisted, it would not be acceptable for ebuilds to rely
+on RESTRICT=sandbox; it would effectively be removing/negating something from the standard
+runtime, rather than suppressing a PM specific extension.  Doing so would lead to the ebuild
+breaking compatibility across PMs, and locking into just the managers that support that RESTRICT.
+
+In the cases where the PM supports an extension to the runtime beyond the PM standard, it is the
+ebuild authors choice as to whether or not use the equivalent RESTRICT token for that PM.  An example
+would be fakeroot; if a package manager adds support for that (functionality not required by the
+standard PMS runtime), a RESTRICT=fakeroot could be added and relied upon by that ebuild; the PM via
+adding that new functionality is responsible for getting ebuild devs to adopt the equivalent RESTRICT,
+and for ensuring they're not introducing arbitrary breakage via that feature.
+
+Essentially, the addition of a non-whitelisted RESTRICT value must be to suppress a PM
+specific extension; if the PM doesn't support that RESTRICT (thus doesn't support that feature), the
+ebuild must work.  If the RESTRICT value cannot meet that requirement, it cannot be relied upon.
 
 \subsection{Properties}
 \label{sec:properties}
-- 
1.7.12