4 [ ] Remove duplicated implementations, and convert everyone to the new
5 data and parse methods.
7 [ ] Comment/Docs Audit.
8 [.] Implement API testing using doctest.
10 [ ] Support $${VAR} or \${VAR} for something we want passed to the shell
11 without being interpreted as an OE variable.
12 [ ] Alter 'export' handling, to support exporting a var without
13 defining the variable.
15 export [VAR[=value] ...]
16 [ ] Possibility: alternate data formats for metadata (i.e. arrays).
19 [ ] More complex variable setting/conditionals
21 [ ] Add support for 'anonymous' OE functions in .oe{,class} files.
22 These functions are to be executed immediately at parse time,
23 thereby giving one the ability to exert more control over the set
25 [ ] if/elseif/else/endif blocks for conditional variable setting
26 [ ] Add "noinherit", as a means of removing an item from the
27 list of classes to inherit.
28 [ ] Need a way to specify that you cannot build a given .oe,
29 from the .oe. Along the lines of portage's ability for
30 an ebuild to specify that it isnt buildable for a given
31 architecture or set of architectures.
32 [ ] Write helper functions ala ebuild's dobin/dodoc/etc and debian's dh_*.
33 [ ] Note, if we do this using actual commands within the .oe file
34 as opposed to shell helpers, the buildsystem is then aware
35 of what files are libs, what are includes, etc, and we could
36 then do a sane automatic population of staging based on that
39 [ ] Make Fetch use md5 hashing to indicate per-file download success.
40 Or in the case of downloaded directories (cvs/svn/bk), simply a
41 success stamp on a per file basis.
43 [ ] Metadata exchange through multiple oebuild/oemake/oespawn executions
44 (i.e. to set qpedir/qtdir for all builds from the qt/opie/qtopia .oe's)
45 [ ] Split staging by package
46 [ ] When a package populates staging, create links for every item
47 that this .oe Provides.
48 [ ] Wouldnt be a bad idea to make use of update-alternatives
49 to manage buildroot's staging links, thereby allowing us
50 to deal with multiple provides sanely (priority).
51 [ ] More complex set of FLAGS vars, to account for the various DEPENDS.
53 ipkg depends on virtual/libc, puts staging_dir/libc in flags.
54 glibc staging creates symlinks for every atom it PROVIDES,
55 and installs its staging files into the glibc-ver-rev dir.
56 [ ] Revamp category handling
57 [ ] Completely revamp packaging classes. Swallow stdout & stderr of
58 tool used, output our own status, and include HOST_ARCH in tarfn.
61 [ ] Implement and test check_md5, taking nostamp into account.
62 [ ] Add '--undo'/'-u' cmdline opt that calls the 'undo' task
63 for the supplied task.
64 [ ] Add '--rebuild'/'-r' cmdline opt that calls the 'undo' task
65 for the entire upward path in the digraph, then builds that task.
66 (same thing done when the md5 changes on an affected var in
68 [ ] Add '--short-circuit'/'-s' cmdline opt that skips task dependencies
69 and calls the specified task directly.
72 [ ] Check for recursive dependency
73 [ ] Deal with multiple provides
76 [ ] Monitor the stamps for a given .oe file as well, to ensure
77 changes in build state as well as changes to build metadata result
83 [ ] {pre,post}{inst,rm}
96 [.] transition packages from OpenZaurus buildroot
97 [ ] all packages need deviceisms added
98 [ ] all packages need output packaging dealt with properly, and
99 packaging granularity increased.
101 [ ] /etc/modules & /etc/modules.conf
103 [ ] New c++ OE library (possibility -- open to debate)
106 * Newly architected with no remnant cruft from portage.
107 * Easier bindings for non-python tools that utilize OE.
108 * Use existing fetch routines from apt-get.
109 * Easier use of libkconfig.
112 * Development time / Wheel reinvention
114 [ ] Data structure(s) for metadata and metadata store
117 [ ] lex/yacc (flex/bison)
118 [ ] Code execution, status and event handling
122 [ ] Fetching things from upstream
123 [ ] Possibly utilize apt-get "methods"
128 [ ] XML/RPC control and metadata exchange interfaces