updates...

6 files changed, 83 insertions, 40 deletions

diff --git a/rewrite-misc/ChangeLog b/rewrite-misc/ChangeLog
index 46c62ae..5eadc59 100644
--- a/rewrite-misc/ChangeLog
+++ b/rewrite-misc/ChangeLog
@@ -1,3 +1,4 @@
+06/11/05: harring: negate added to restriction base, work in package.* and ebuild.package
 06/07/05: harring: config.{repo,cache,domain,sync} works fine, new dict type.  portage.util.dicts holds the dict variants, including
 	IndexableSequence.  added portage.util.currying.  Use it.  it rocks.
 06/07/05: harring: config instantation of repo works now.  config.repo is a bit screwed up, but will be fixed.
diff --git a/rewrite-misc/HORKED b/rewrite-misc/HORKED
index d525812..120ac7e 100644
--- a/rewrite-misc/HORKED
+++ b/rewrite-misc/HORKED
@@ -11,8 +11,8 @@ portage.cache.multiplex # should be a master/slave class, master for querying, b
 portage.restrictions
 potage.config.central	# need's to be renamed, and needs new.instancemethod hacks, read intro for explanation.
 
-portage.vdb		# consult harring if you're after this, since this is a helluva lot more complex then just a repo
-portage.binpkg	# bind it to portage.ebuild whereever possible
+portage.vdb					# consult harring if you're after this, since this is a helluva lot more complex then just a repo
+portage.binpkg				# bind it to portage.ebuild whereever possible
 
 not started
 portage.config.domain	# consult intro doc if you attempt it, and collect feedback from jason/brian regarding it please
diff --git a/rewrite-misc/conf_default_types b/rewrite-misc/conf_default_types
index c8dfc13..992352c 100644
--- a/rewrite-misc/conf_default_types
+++ b/rewrite-misc/conf_default_types
@@ -42,7 +42,7 @@
 # decide if this is good or bad.  in effect, require's are generalized for a section type, which may not apply
 #
 # there isn't any mechanism for noting what supports interop (think sync + repo), aside from instantiating
-# and having it bitch.  fluid design/intention of the final parsing of user config, but this is a drawback of 
+# and having it complain.  fluid design/intention of the final parsing of user config, but this is a drawback of 
 # said design.
 # think about ways to curb that, lest users get too annoying with tracebacks ;)
 #
@@ -54,7 +54,7 @@
 # a location on the fs that defines further defaults, although that makes parsing this file fun.
 #
 # short version, with the rules established, you would need to define a metasection, and apply the 
-# inherit/incrementals crap to constructing at run time the section definitions.
+# inherit/incrementals cruft to constructing at run time the section definitions.
 # or you need a smarter parser/generator for this file.
 # leave that to the schmuck who writes the autotools integration for this
 # (why oh why do I suspect that's going to be my stupid ass? :)
@@ -79,11 +79,10 @@
 
 
 [profile]
-incrementals = USE FEATURES ACCEPT_KEYWORDS ACCEPT_LICENSE CONFIG_PROTECT_MASK CONFIG_PROTECT PRELINK_PATH PRELINK_PATH_MASK
-list = USE FEATURES ACCEPT_KEYWORDS ACCEPT_LICENSE CONFIG_PROTECT_MASK CONFIG_PROTECT PRELINK_PATH PRELINK_PATH_MASK 
-	package.keywords package.use package.unmask package.mask
-defaults = class
-class = portage.ebuild.profiles.oldstyle
+incrementals = %(default_incrementals)s 
+list = %(default_incrementals)s package.keywords package.use package.unmask package.mask
+defaults = class incrementals
+class = portage.ebuild.ebuild.profile.OnDiskProfile
 required = class
 
 [domain]
@@ -91,9 +90,8 @@ instantiate = portage.config.parser.domain
 required = repositories profile root class
 section_ref = repositories profile
 pre = config repositories
-incrementals = USE FEATURES ACCEPT_KEYWORDS ACCEPT_LICENSE CONFIG_PROTECT_MASK CONFIG_PROTECT PRELINK_PATH PRELINK_PATH_MASK
-list = USE FEATURES ACCEPT_KEYWORDS ACCEPT_LICENSE CONFIG_PROTECT_MASK CONFIG_PROTECT PRELINK_PATH PRELINK_PATH_MASK
-	package.keywords package.use package.unmask package.mask repositories
+incrementals = %(default_incrementals)s
+list = %(default_incrementals)s package.keywords package.use package.unmask package.mask repositories
 defaults = class root
 class =  portage.config.domain
 root = /
@@ -130,3 +128,5 @@ class = portage.sync.rsync
 metadata_keys = DEPEND RDEPEND SLOT SRC_URI RESTRICT HOMEPAGE LICENSE DESCRIPTION KEYWORDS INHERITED IUSE CDEPEND
    PDEPEND PROVIDE
 cache_base_loc = /var/cache/edb/dep/
+default_incrementals = USE FEATURES ACCEPT_KEYWORDS ACCEPT_LICENSE CONFIG_PROTECT_MASK CONFIG_PROTECT PRELINK_PATH PRELINK_PATH_MASK
+
diff --git a/rewrite-misc/config b/rewrite-misc/config
index 2e6eabf..c9d218a 100644
--- a/rewrite-misc/config
+++ b/rewrite-misc/config
@@ -13,7 +13,6 @@ cache = '/usr/portage'
 #location = /var/db/pkg
 
 [base config]
-type = config
 USE = nptl nptlonly -gnome -oss mad matroska faad mpg avi -arts mmx mmxext flac bidi dvd ssl sdl xvid 3dnow 3dnowext 
 	sse sse2 mythtv rtc -svga -ipv6 win32codecs -esd
 DISTDIR = "/space/distfiles"
@@ -34,11 +33,10 @@ CHOST = "i686-pc-linux-gnu"
 profile = profile
 inherit = 'base config'
 ACCEPT_KEYWORDS = "x86"
-inherit = 'base config'
 
 [livefs domain]
-inherit = x86
 type = domain
+inherit = x86
 default = yes
 repositories = "rsync repo" 
 #vdb
diff --git a/rewrite-misc/config.txt b/rewrite-misc/config.txt
index ea360ed..6d4f37d 100644
--- a/rewrite-misc/config.txt
+++ b/rewrite-misc/config.txt
@@ -1,13 +1,10 @@
 ===NOTE===
 If you're _truly_ interested in what config does/supports currently, look at conf_default_types.  lot of info there.
-This is kept for historical reasons, and cause it explains the idea/layout a bit more
-That said, it _is_ out of date (sorry, shit moves fast), config section no longer exists, it was merged into domain
-
-make.conf backwards compatibility bit still applies, and is pretty straightforward/easy to pull off actually.
+This is general idea of it, actual code/current intentions may differ.
 ~harring
 ===BACK TO YOUR PREVIOUSLY SCHEDULED PROGRAMMING===
 
-win.ini style format (yay).
+win.ini style format (no you cannot burn me at the stake for this, but you're free to try).
 
 sections that define type are acted upon.  no type definition, and the section is ignored unless explicitly inherited
 if type is defined, exempting configs type, class must be defined.
@@ -21,15 +18,13 @@ class = portage.ebuild.repository
 location = /usr/portage
 
 each section is capable of specifying inherit targets.  inherit's specify the base section to pull in, and override.
-can still access the original value via similar bash trick- 
-CFLAGS = %(CFLAGS) -g
-for example.
+depending on the top level type, certain settings may be specified as incrementals.  use flags fex, are incremental.
 
-few words on each section (note the type of the section is declareed explicitly, otherwise it's just a config 'group' that is only
+few words on each section (note the type of the section is declared explicitly, otherwise it's just a config 'group' that is only
 used by inherit's)
 
 [repo]
-	must specify class
+	class defaults to portage.ebuild.repository
 	REPO_LABEL is automatically defined for all cache instances.
 	frozen is a boolean, specifies if cache staleness is corrected, or errored out.
 	can (and is advisable for rsync) specify a sync_cache.
@@ -46,7 +41,7 @@ used by inherit's)
 [cache]
 	must specify class
 	REPO_LABEL is available; it's the repo 'label' (section, really) that the cache is associated with (repo specifies this)
-	if no path is specified, assumed path is %(CONFIG_PATH)/%(REPO_LABEL) (# change in behaviour, but not user visible)
+	if no path is specified, assumed path is portage's base cache path, usually /var/cache/edb/dep
 	can only be bound to a repo
 
 [config]
diff --git a/rewrite-misc/intro b/rewrite-misc/intro
index 06812a0..64c4f0a 100644
--- a/rewrite-misc/intro
+++ b/rewrite-misc/intro
@@ -15,10 +15,11 @@ Other subsystems/design choices have their basis quite likely from other docs in
 
 
 [FURTHER DISCLAIMER]
-If this is implemented, which is being attempted, this is going to break the hell out of backwards compatibility api wise.
+If this is implemented, which is being attempted, this is going to break backwards compatibility for existing python api.
 Writing a translation layer doesn't really seem possible either, since things are pretty radically different (imho)
 
-Sorry, but thems the breaks.  Feel free to attempt it, but this docs author doesn't view it as possible/viable
+Sorry, but thems the breaks.  Feel free to attempt it, but this docs author doesn't view it as a good use of time, since old api was 
+useful for querying, about it.
 
 
 [Terminology]
@@ -30,6 +31,8 @@ domain	= combination of repositories, root, and build information (use flags, cf
 repository = tree's.  ebuild tree (/usr/portage), binpkg tree, vdb tree, etc.
 protocol	= python name for design/api.  iter() fex, is a protocol; it calls .next() on the passed in sequence, or wraps the sequence...
 			  hesitate to call it defined hook on a class/instance, but this (crappy) description should suffice.
+seq		= sequence, lists/tuples
+set		= list without order (think dict.keys())
 
 [General design/idea/approach]
 So... this round of "lets take another stab at gutting portage" seems to be proceeding, and not killed off by design flaws *again*
@@ -48,8 +51,8 @@ Assume what you're delegating to knows what the hell it's doing, and probably ca
 Actual configuration is pretty heavily redesigned.  Look at conf_default_types (likely renamed at some point).
 It's the meta-definition of the config... sort of.  Basically the global config class knows jack, is generic, and is configured by the
 conf_default_type.  The intention is that the on disk configuration format is encapsulated, so it can be remote or completely different 
-from the win.ini format advocated by harring (mainly cause it's easiest since a functional and mostly not completely fricking 
-obnoxious parser exists already).
+from the win.ini format advocated by harring (mainly cause it's easiest since a functional and mostly not completely obnoxious parser 
+exists already).
 
 Encapsulation, extensibility/modularity, delegation, and allowing parallelizing of development should be key focuses in 
 implementing/refining this high level design doc.
@@ -62,11 +65,27 @@ Final comment re: design goals, defining chunks of callable code and plugging it
 Think twisted, just not quite as prevalent (their needs/focus is much different from ours, twisted is the app, your code is the lib, 
 vice versa for portage).
 
-Back to config.  Here's general notion of config 'chunks' (these map out to run time objects)
+Back to config.  Here's general notion of config 'chunks' of the subsystem, (these map out to run time objects unless otherwise stated)
 
-domain--------------\
-|						  |
-repository			  profile
+domain
++-- profile (optional)
++-- fetcher (default)
++-- repositories
++-- resolver (default)
++-- build env data?
+|    never actually instantiated, no object)
+\-- livefs_repo (merge target, non optional)
+
+repository
++-- cache   (optional)
++-- fetcher (optional)
++-- sync    (optional)
+\-- sync cache (optional)
+
+profile
++-- build env?
++-- sets (system mainly).
+\-- visibility wrappers
 
 domain is configuration data, accept_(license|keywords), use, cflags, chost, features, etc.
 profile, dependant on the profile class you choose is either bound to a repository, or to user defined location on disk 
@@ -75,7 +94,7 @@ wrappers for repositories also.
 
 repositories is pretty straightforward.  portdir, binpkg, vdb, etc.
 
-Back to domain.  Domain's are you definition of pretty much what can be done.  Can't do jack without a domain, period.
+Back to domain.  Domain's are your definition of pretty much what can be done.  Can't do jack without a domain, period.
 Can have multiple domains also, and domains do *not* have to be local (remote domains being a different class type).
 Clarifying, think of 500 desktop boxes, and a master box that's responsible for managing them.  Define an appropriate domain class, 
 and appropriate repository classes, and have a config that holds the 500 domains (representing each box), and you can push updates out
@@ -90,19 +109,26 @@ code needed in parallel to fleshing portage proper out.
 Meanwhile, the remote bit + multiple domains + class overrides in config definition is _explicitly_ for the reasons above.  That 
 and x-compile/embedded target building, which is a bit funkier.
 
-Currently, portage has DEPEND and RDEPEND.  How do you know what needs be native to that box to build the package?  
+Currently, portage has DEPEND and RDEPEND.  How do you know what needs be native to that box to build the package, what must be chost atoms?  
 Literally, how do you know which atoms, say the toolchain, must be native vs what package's headers/libs must exist to build it?
 We need an additional metadata key, BDEPEND (build depends).
 
 If you have BDEPEND, you know what actually is ran locally in building a package, vs what headers/libs are required.
-Subtle differance, but BDEPEND would allow (with a sophisticated depresolver) toolchain to be represented in deps, rather then 
+Subtle difference, but BDEPEND would allow (with a sophisticated depresolver) toolchain to be represented in deps, rather then 
 the current unstated dep approach profiles allow.
 
 Aside from that, BDEPEND could be used for x-compile via inter-domain deps; a ppc target domain on a x86 box would require BDEPEND 
 from the default domain (x86).  So... that's useful.
 
-Not yet proposed to dev ml, and adds to developer workload slightly, although it's a worthwhile sell.
+So far, no one has shot this down, moreso, come up with reasons as to why it wouldn't work, the consensus thus far is mainly 
+"err, don't want to add the deps, too much work".  Regarding work, use indirection.
 
+virtual/toolchain-c <-- metapkg (glep37) that expands out (dependant on arch) into whatever is required to do building of c sources
+virtual/toolchain-c++ <-- same thing, just c++
+virtual/autootols	<-- take a guess.
+virtual/libc		<-- this should be tagged into rdepends where applicable, packages that directly require it (compiled crap mainly)
+
+Yes it's extra work, but the metapkgs above should cover a large chunk of the tree, say >90%.
 
 [Config design]
 Portage thus far (<=2.0.51*) has had variable ROOT (livefs merge point), but no way to vary configuration data aside from via a buttload of 
@@ -151,6 +177,12 @@ hesitate to call it a general api, but it probably will be as such, exempting an
 functions as a set and dict, with caching and on the fly querying of info.
 mentioned due to use in repository and other places... (it's a useful lil sucker)
 
+This actually is misnamed.  the order of iteration isn't necessarily reproducable, although it's usually constant.
+IOW, it's normally a sequence, but the class doesn't implicitly force it
+
+
+:LazyValDict:
+similar to ixseq, late loading of keys, on fly pulling of values as requested.
 
 :global config object (from portage.config.load_config()):
 #simple bugger.
@@ -173,7 +205,7 @@ domain = some-section-label
 
 :domain object:
 # bit of debate on this one I expect.
-# any package.{mask,unmask,keywords} mangling is instantiating as a wrapper around repository instances upon domain instantiation.
+# any package.{mask,unmask,keywords} mangling is instantiated as a wrapper around repository instances upon domain instantiation.
 # code _should_ be smart and lift any package.{mask,unmask,keywords} wrappers from repositoriy instances and collapse it, pointing
 # at the raw repo (basically don't have N wrappers, collapse it into a single wrapper).  Not worth implementing until the wrapper is 
 # a faster implementation then the current portage.repository.visibility hack though (currently O(N) for each pkg instance, N being 
@@ -330,6 +362,23 @@ continuing on...
 				# clarification, you don't call this directly, repo.match delegates off to this for metadata only restrictions
 
 
+:package:
+# this is a wrapped, *constant* package.  configured ebuild src, binpkg, vdb pkg, etc.
+# ebuild repositories don't exactly and return this- they return unconfigured pkgs, which I'm not going to go into right now
+# (domains only see this protocol, visibility wrappers see different)
+.depends		# usual meaning.  ctarget depends
+.rdepends	# usual meaning.  ctarget run time depends. seq,
+.bdepends	# see ml discussion.  chost depends, what's executed in building this (toolchain fex).  seq.
+.files		# get a better name for this.  doesn't encompas files/*, but could be slipped in that way for remote.  encompasses 
+				# restrict fetch (files with urls), and chksum data.  seq.
+.description# usual meaning, although rememebr probably need a way to merge metadata.xml lond desc into the more mundane description key.
+.license		# usual meaning, seq.
+.homepage	# usual.  needed?
+.setup()		# name sucks.  gets ya the 
+setup operation, which does building/whatever.
+.data			# raw data.  may not exist, don't screw with it unless you know what it is, and know the instance's .data layout.
+
+
 :restriction:
 # see layout.txt for more fleshed out examples of the idea.
 # note, match and pmatch have been reversed namewise.
@@ -339,7 +388,7 @@ continuing on...
 				# get the jist?  it holds the actual test, if the restriction can be collapsed down to a test of a single value.
 				# .pmatch calling should only be done by self, or code that does isinstance checks and hands off data itself rather then
 				# doing an instantion.  .pmatch is exposing a bit of the match protocol so that optimizations are potentially possible in 
-				# executing match checks (think repo.match).
+				# executing match checks (think repo.match).  this one is still slightly up in the air.  naming sucks also.
 .itermatch() # new one, debatable.  short version, giving a sequence of package instances, yields true/false for them.
 				# why might this be desirable?  if setup of matching is expensive, this gives you a way to amoritize the cost.
 				# jason/marius/alec, thoughts?