Delete: doc/TODO

1 files changed, 0 insertions, 128 deletions

diff --git a/doc/TODO b/doc/TODO
deleted file mode 100644
index 2717a9761..000000000
--- a/doc/TODO
+++ /dev/null
@@ -1,128 +0,0 @@
-TODO:
-
-[x] oe package
-	[ ] Remove duplicated implementations, and convert everyone to the new
-	    data and parse methods.
-	[ ] API Sanity Audit.
-	[ ] Comment/Docs Audit.
-	[.] Implement API testing using doctest.
-	[ ] Parsing
-		[ ] Support $${VAR} or \${VAR} for something we want passed to the shell
-		    without being interpreted as an OE variable.
-		[ ] Alter 'export' handling, to support exporting a var without
-		    defining the variable.
-			format:
-			export [VAR[=value] ...]
-		[ ] Possibility: alternate data formats for metadata (i.e. arrays).
-			i.e. THIS[1] = "that"
-			     THIS["heh"] = "that"
-		[ ] More complex variable setting/conditionals
-			Options:
-			[ ] Add support for 'anonymous' OE functions in .oe{,class} files.
-			    These functions are to be executed immediately at parse time,
-			    thereby giving one the ability to exert more control over the set
-			    of variables.
-			[ ] if/elseif/else/endif blocks for conditional variable setting
-		[ ] Add "noinherit", as a means of removing an item from the
-		    list of classes to inherit.
-		[ ] Need a way to specify that you cannot build a given .oe,
-		    from the .oe.  Along the lines of portage's ability for
-		    an ebuild to specify that it isnt buildable for a given
-		    architecture or set of architectures.
-		[ ] Write helper functions ala ebuild's dobin/dodoc/etc and debian's dh_*.
-			[ ] Note, if we do this using actual commands within the .oe file
-			    as opposed to shell helpers, the buildsystem is then aware
-			    of what files are libs, what are includes, etc, and we could
-			    then do a sane automatic population of staging based on that
-			    information. 
-	[ ] Fetch
-		[ ] Make Fetch use md5 hashing to indicate per-file download success.
-		    Or in the case of downloaded directories (cvs/svn/bk), simply a 
-		    success stamp on a per file basis.
-	[ ] Data
-		[ ] Metadata exchange through multiple oebuild/oemake/oespawn executions
-		    (i.e. to set qpedir/qtdir for all builds from the qt/opie/qtopia .oe's)
-	[ ] Split staging by package
-		[ ] When a package populates staging, create links for every item
-		    that this .oe Provides.
-			[ ] Wouldnt be a bad idea to make use of update-alternatives
-			    to manage buildroot's staging links, thereby allowing us
-			    to deal with multiple provides sanely (priority).
-		[ ] More complex set of FLAGS vars, to account for the various DEPENDS.
-		[ ] Example:
-			ipkg depends on virtual/libc, puts staging_dir/libc in flags.
-			glibc staging creates symlinks for every atom it PROVIDES,
-			and installs its staging files into the glibc-ver-rev dir.
-	[ ] Revamp category handling
-	[ ] Completely revamp packaging classes.  Swallow stdout & stderr of
-	    tool used, output our own status, and include HOST_ARCH in tarfn.
-	
-[ ] oebuild
-	[ ] Implement and test check_md5, taking nostamp into account.
-	[ ] Add '--undo'/'-u' cmdline opt that calls the 'undo' task
-	    for the supplied task.
-	[ ] Add '--rebuild'/'-r' cmdline opt that calls the 'undo' task
-	    for the entire upward path in the digraph, then builds that task.
-	    (same thing done when the md5 changes on an affected var in
-	     check_md5)
-	[ ] Add '--short-circuit'/'-s' cmdline opt that skips task dependencies
-	    and calls the specified task directly.
-
-[.] oemake
-	[ ] Check for recursive dependency
-	[ ] Deal with multiple provides
-
-[ ] oemaked
-	[ ] Monitor the stamps for a given .oe file as well, to ensure
-	    changes in build state as well as changes to build metadata result
-	    in a rebuild.
-
-[.] oeinstall
-	[.] types
-		[x] direct
-			[ ] {pre,post}{inst,rm}
-		[ ] tarball
-		[ ] rpm
-		[ ] deb
-		[ ] ipkg
-[.] oeimage
-	[.] types
-		[x] jffs2
-		[ ] ext2
-		[ ] cramfs
-		[ ] tarball
-
-[.] packages
-	[.] transition packages from OpenZaurus buildroot
-		[ ] all packages need deviceisms added
-		[ ] all packages need output packaging dealt with properly, and
-		    packaging granularity increased.
-		[ ] modutils
-			[ ] /etc/modules & /etc/modules.conf
-
-[ ] New c++ OE library (possibility -- open to debate)
-
-	Benefits:
-		* Newly architected with no remnant cruft from portage.
-		* Easier bindings for non-python tools that utilize OE.
-		* Use existing fetch routines from apt-get.
-		* Easier use of libkconfig.
-
-	Liabilities:
-		* Development time / Wheel reinvention
-
-	[ ] Data structure(s) for metadata and metadata store
-	[ ] .oe parser
-		[ ] manual
-		[ ] lex/yacc (flex/bison)
-	[ ] Code execution, status and event handling
-		[ ] Build
-		     '----Package
-			     '----Task
-	[ ] Fetching things from upstream
-		[ ] Possibly utilize apt-get "methods"
-			[ ] CVS method
-			[ ] BK method
-			[ ] SVN method
-	[ ] Autobuild daemon
-		[ ] XML/RPC control and metadata exchange interfaces