general seperated out docs/comments/questions/issues

5 files changed, 91 insertions, 0 deletions

diff --git a/rewrite-misc/configurables b/rewrite-misc/configurables
new file mode 100644
index 0000000..558f8f5
--- /dev/null
+++ b/rewrite-misc/configurables
@@ -0,0 +1,17 @@
+Yet Another Harring Random Notes File (henceforth known as YAHRF)
+
+portage.ebuild.ebuild_repository is unconfigured packages, with the reasoning that as a repo, it's not supposed to know 
+about config crap (encapsulation); you wrap it with a configurator, which wraps the base package with configuration data, 
+generated a flattened *depends, src_uri, license, keywords, etc.
+
+The issue is how to handle restrictions coming in that change the wrapper.
+( ( x in use ) and AlwaysFalse ) || ( x not in use )
+^^^ how to handle this?  Effectively the wrapper needs resetting, but that probably won't work perfectly either.
+need to break it down into a tree of non-modifying restrictions
+stack based cmatch?
+push/pop modifications?
+
+here's how we do it.
+running count of changes on a configurable pkg
+each restriction that holds sub restrictions (recursive, think AndRestrictionSet fex), grabs a counter from the pkg, 
+if failed run, unwinds changes down to the level it saw, and pukes the pkg back if negate, or None
diff --git a/rewrite-misc/eapi b/rewrite-misc/eapi
new file mode 100644
index 0000000..2659ded
--- /dev/null
+++ b/rewrite-misc/eapi
@@ -0,0 +1,14 @@
+Note: document in process. please update as this (initially) is just a quick jotting down
+
+This should hold the proposed (with a chance of making it in), and accepted/implemented changes for ebuild format version 1.
+bit hard to do, but a version 0 doc (current internal implementation/behaviour) would be good also.
+
+[Version 0 (or undefined eapi, <=portage-2.0.52*)]
+
+[Version 1]
+EAPI=1 required, at some point likely assumed but not yet.
+configure phase exists; src_configure is the function.
+RDEPEND="${RDEPEND-${DEPEND}}" autosetting no longer exists.
+addition of elib function, which notes the file to source, then sources it post global ebuild sourcing.
+(proposed) BDEPEND metadata addition.
+
diff --git a/rewrite-misc/licenses b/rewrite-misc/licenses
new file mode 100644
index 0000000..7a25aaf
--- /dev/null
+++ b/rewrite-misc/licenses
@@ -0,0 +1,8 @@
+08/08
+hokay, just added license support; issue with it's implementation though, there's no negation yet.
+currently it's effectively for the filter-
+not ( licenses in $ACCEPT_LICENSES || licenses in package.license )
+to support negation, needs to be
+not ( licenses in package.license || ( licenses in $ACCEPT_LICENSES && not licenses in (filtered) package.license ) )
+so... anyone after getting it added (I'll do it when I get around to it), poke in portage.config.domain.domain
+
diff --git a/rewrite-misc/notes b/rewrite-misc/notes
new file mode 100644
index 0000000..22c4cb0
--- /dev/null
+++ b/rewrite-misc/notes
@@ -0,0 +1,4 @@
+ebuild KEYWORDS "-*" probably is going to be dropped unless somebody has a damn good arg for it.
+effectively, it blocks ACCEPT_KEYWORDS="whatever-arch" emerge some-ebuild
+it works cause of the stacked nature of config in stable; can do it in rewrite, but it's ugly and (personally) I don't think it's
+properly implemented (use package.mask)
diff --git a/rewrite-misc/restrictions b/rewrite-misc/restrictions
new file mode 100644
index 0000000..3265d4b
--- /dev/null
+++ b/rewrite-misc/restrictions
@@ -0,0 +1,48 @@
+# general info/commentary on restrictions.  see layout.txt for historical background.
+
+general protocol is simple,
+
+def match(self, pkginst) 
+
+is all that's expected.  pkginst being an instance like portage.ebuild.ebuild_package.
+all base restrictions chunks should support the negate option, usually via something akin to this in match
+return boolean-value-for-this-match ^ self.negate
+
+Individual restrictions are built up via portage.restrictions.restriction .  Str matches, package data matches, etc,
+are covered by that module.  More likely then not, people will need to be able to bind restrictions together via boolean ops;
+these 'sets' of restrictions (they're technically sequences) are in portage.restrictions.restrictionSet.
+
+AndRestrictionSet # boolean and
+OrRestrictionSet	# boolean or
+XorRestrictionSet	# boolean xor
+
+The sequences above support negate also (unless it makes no sense whatsoever, negation (effectively 'not restrict.match(blah)'), 
+should be supported.
+
+If you need another base boolean op, *please* generalize it in restrictionSet so that everyone can share the wealth. :)
+
+Keep an eye on not creating 101 different restriction types.  If possible, build up from basic chunks.
+
+Why?  For a remote repository implementation, it *will* have to translate the restrictions into it's own internal querying format 
+fex, an atom, AndRestrictionSet(pkg cat attribute strexact, pkg name attribute strexact, pkg ver attribute versmatch), 
+=dev-util/diffball-0.6.5,  for an rdbms backend would be *best* to translate into sql, 
+essentially `WHERE (category="dev-util" AND package="diffball" and version="0.6.5")`.
+
+If a lego like approach is used (eg, small blocks, building up more complex blocks from the original bases) translation of the 
+bases *should* make conversion from restriction elements to internal format *much* easier, mainly attainable.
+
+Aside from that, keep an eye on the restriction implementations; be aware that there may be *lots* of them.  As of the time of this writing,
+$PORTDIR/profiles/package.mask comes out to around 938 seperate restricts, with 353 boolean ands (1291 total).
+Use __slots__ for the classes, or consider implementing a flywheel design, point is, keep them as small as possible, with a careful
+eye on execution.
+
+Example: a simple error involving an extra set of unnecssary function calls in the restrict base, once corrected, accounted for a 150x
+reduction in run time on p.mask filtering of a repository (3.4s to 0.022s).  Effectivelly, you're defining chunks of executable code 
+thrown around to do verification, as such, keep in mind they'll be ran a *lot*.
+Profile the suckers, iow.
+
+Beyond that, restrict base classes probably are candidates for conversion to cpython, although experimenting with that should come down
+the line (prototype and get it running first, then see if you can shave 5-10% off from the conversion).
+
+
+Combining restrictions: (containment tests, ya ya)