From e74d3456b50efca2e50b9c18be5faa66ec1ac67a Mon Sep 17 00:00:00 2001 From: graham.gower Date: Tue, 24 Nov 2009 20:41:01 -0500 Subject: Update README and TODO. Add myself to AUTHORS. git-svn-id: http://opkg.googlecode.com/svn/trunk@367 e8e0d7a0-c8d9-11dd-a880-a1081c7ac358 --- diff --git a/AUTHORS b/AUTHORS index 1e807b8..e7ce307 100644 --- a/AUTHORS +++ b/AUTHORS @@ -1,6 +1,7 @@ Opkg: * Thomas Wood * Tick Chen + * Graham Gower Ipkg: * Pierluigi Frullani * Carl Worth diff --git a/README b/README index bb2cf99..cf20f1f 100644 --- a/README +++ b/README @@ -3,5 +3,10 @@ OPKG Package Management System Opkg is a lightweight package management system based on Ipkg. -Website: http://wiki.openmoko.org/wiki/Opkg -Mailing list: http://lists.openmoko.org/mailman/listinfo/opkg-devel +Website: http://code.google.com/p/opkg/ +Mailing list: http://groups.google.com/group/opkg-devel +Bug tracker: http://code.google.com/p/opkg/issues/list + +The previous website can still be found at: +http://wiki.openmoko.org/wiki/Opkg + diff --git a/TODO b/TODO index 2d0c156..e54ffa7 100644 --- a/TODO +++ b/TODO @@ -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 -- cgit v0.9.1