diff options
author | 2005-08-09 08:42:20 +0000 | |
---|---|---|
committer | 2005-08-09 08:42:20 +0000 | |
commit | 3be96a95cc926f1a35a784ac468ef4877b7e3ce4 (patch) | |
tree | 46a8aadf148de837be98a40dd98411723398b4e5 | |
parent | update for ACCEPT_LICENSE filtering (diff) | |
download | portage-cvs-3be96a95cc926f1a35a784ac468ef4877b7e3ce4.tar.gz portage-cvs-3be96a95cc926f1a35a784ac468ef4877b7e3ce4.tar.bz2 portage-cvs-3be96a95cc926f1a35a784ac468ef4877b7e3ce4.zip |
general seperated out docs/comments/questions/issues
-rw-r--r-- | rewrite-misc/configurables | 17 | ||||
-rw-r--r-- | rewrite-misc/eapi | 14 | ||||
-rw-r--r-- | rewrite-misc/licenses | 8 | ||||
-rw-r--r-- | rewrite-misc/notes | 4 | ||||
-rw-r--r-- | rewrite-misc/restrictions | 48 |
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) |