diff options
Diffstat (limited to 'TODO')
| -rw-r--r-- | TODO | 68 |
1 files changed, 26 insertions, 42 deletions
@@ -1,62 +1,46 @@ -Things to do for opkg, in a partial order: -1) Bug fixes +See issue list: http://code.google.com/p/opkg/issues/list -1.a) fix all code marked "XXX: BUG" -1.b) fix all outstanding opkg bugzilla bugs + * Regression test suite. -1.c) Make sure Suggests, Recommends, (Enhances?), all work, (I know - some of these are not yet implemented) + * Fix comments marked "XXX". -1.d) Audit all dpkg package fields for both parsing and printing support. + * Clean up out of date comments. -1.e) "opkg status" and "opkg info" need to complain about unknown - packages. For that matter, these two commands should probably just - become aliases to the same functionality. + * Consistent indentation. + * Propagate errors up the call stack. In particular, unarchive.c fails to do + this. Errors and error messages must be usable by libopkg frontends. + Don't try to use errno after its been clobbered by other libc calls. -2) Implement new features + * Remove dead and duplicate code. Refactor duplicated functionality. -2.a) start with all "XXX: FEATURE" comments + * Reduce memory used per pkg_t and peak memory use in general. -2.b) implement all accepted opkg bugzilla feature requests, (also - check old post "Subject: Reinventing opkg" to see if we forgot - any of the good ideas we had once upon a time) + * Refactor opkg_conf_t *conf. + Make it global instead of passing it to every function. + Remove args_t args in favour of conf. -2.c) Add support for: - opkg install foo from some-feed - opkg install foo-0.4.3 - opkg install foo-latest # Only needed if we add a feed-order-priority option - or something like that. + * #includes are a mess. -2.d) Experiment with making a small statically linked binary. Can we - eliminate some library calls, (glob, regcomp)? Can we get - something like uclibc to work well? + * Refactor opkg_install_pkg() into more precise functions. -2.e) Add support for a deb-src in /etc/opkg.conf. (ARGH! Name clash - alert! In apt-land, deb-src means something very different than - what I would mean here. Hrm... Maybe src-deb would be cleaner? ) - - (What is this? Jamey 7/23/2002) + * pkg_hash_fetch_best_installation_candidate() is linear search O(P*PN) + and is slow (frequently called). + P provider + PN pkgs in a provider + It can be O(P) if a hash table is used. -2.f) Figure out a clever chroot mechanism for running maintainer scripts in - offline_root mode. + * Update libbb. -2.g) Implement opkg history mechanism, with undo and redo? Keep track of - packages removed/installed by each call to opkg. -3) Cleanup the code +FEATURES -3.a) Start with all comments marked "XXX: CLEANUP" + * Start with all "XXX: FEATURE" comments. Remove them if they are bogus. -3.b) Clean up out of date comments. That really confusing + * Implement chrooting to an offline_root for running maintainer scripts. -4) refactorying opkg_install_pkg into more precise functions -4.1) refactory upgrade list first -4.2) Finding canditate is linear search O(P*PN) and is very slow (been called very frequently) - P provider - PN pkgs in a provider - It's can be O(P) if there we use hash table. - It should be refacotry to a faster one. + * Improve dpkg compatibility, according to the Debian Policy Manual. + http://www.debian.org/doc/debian-policy/ch-controlfields.html |