diff options
author | Dan McGee <dan@archlinux.org> | 2007-06-27 22:33:27 +0200 |
---|---|---|
committer | Dan McGee <dan@archlinux.org> | 2007-06-28 02:32:37 +0200 |
commit | 77bbe581973d41d57edb96488fa2cf73fddc1641 (patch) | |
tree | f022375b86607512a0fbed6b934fb3372b82f7dc /TODO.aaron | |
parent | 3a27fbaae40869d513cf117609d3a56c07863cae (diff) | |
download | pacman-77bbe581973d41d57edb96488fa2cf73fddc1641.tar.gz pacman-77bbe581973d41d57edb96488fa2cf73fddc1641.tar.xz |
Remove TODO items that have been taken care of.
Signed-off-by: Dan McGee <dan@archlinux.org>
Diffstat (limited to 'TODO.aaron')
-rw-r--r-- | TODO.aaron | 16 |
1 files changed, 0 insertions, 16 deletions
@@ -1,23 +1,11 @@ == This is my custom TODO file == -** THIS IS A TEST COMMIT - * transaction object should contain two package list (install and remove) instead of a single list of syncpkgs - this should allow us to get rid of that type. This also requires seperate functionality to return a list of "replaces" packages to the front end, so the frontend can handle the QUESTION() stuff in that case -* Look into other VCSs to use. The main CVS repo will remain, but having a - distributed system to allow for easy patching/pushing/pulling would be nice - - monotone and mercurial look like the top contenders in my book, but I need - to evaluate both a bit more. - -* src/pacman: - There's quite a few single function headers which contain the pacman_* - functions. We should move these to a single header (pacman.h) to clean up - the source a bit. - * libalpm -> front end communication needs a work-up. Both progress functions can be combined into one callback, IFF we adjust it to accept a prefix string for the progress bars, and format it at the lib side. Question functions @@ -47,10 +35,6 @@ * pacman: fixup doxygen documentation for public interface -* libalpm: just because a function is in alpm.h doesn't mean it needs to be in - alpm.c - we should move functions around where they should be. In fact, - alpm.c might not be needed at all, if things were organized properly. - * feature for 3.1: package file hooks * I've been planning on this one for some time. Here's a simple rundown: in /etc/pacman.d/hooks: |