summaryrefslogtreecommitdiffstats
path: root/TODO
blob: 2d0c1566fc99c9fc05f0e390036141b56ddfe35a (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
Things to do for opkg, in a partial order:

1) Bug fixes

1.a) fix all code marked "XXX: BUG"

1.b) fix all outstanding opkg bugzilla bugs

1.c) Make sure Suggests, Recommends, (Enhances?), all work, (I know
     some of these are not yet implemented)

1.d) Audit all dpkg package fields for both parsing and printing support.

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.


2) Implement new features

2.a) start with all "XXX: FEATURE" comments

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)

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.

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?

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) 

2.f) Figure out a clever chroot mechanism for running maintainer scripts in
     offline_root mode.

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

3.a) Start with all comments marked "XXX: CLEANUP"

3.b) Clean up out of date comments. That really confusing

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.