Send patches - preferably formatted by git format-patch - to patches at archlinux32 dot org.
summaryrefslogtreecommitdiff
path: root/TODO.aaron
diff options
context:
space:
mode:
authorDan McGee <dan@archlinux.org>2007-06-27 16:33:27 -0400
committerDan McGee <dan@archlinux.org>2007-06-27 20:32:37 -0400
commit77bbe581973d41d57edb96488fa2cf73fddc1641 (patch)
treef022375b86607512a0fbed6b934fb3372b82f7dc /TODO.aaron
parent3a27fbaae40869d513cf117609d3a56c07863cae (diff)
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.aaron16
1 files changed, 0 insertions, 16 deletions
diff --git a/TODO.aaron b/TODO.aaron
index 83a794d6..b1f78873 100644
--- a/TODO.aaron
+++ b/TODO.aaron
@@ -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: