1 - keep history of installed packages/journal of package transaction,
2 so we can roll back to yesterday, or see what got installed in the
5 - we build a cache of the currently installed set to service
6 dependency inquiries fast:
8 map from property to pkg (as hash) providing it
9 map from property to pkgs requiring it
10 map from pkg name to manifest
11 map from string to string pool index
13 no implicit provides? not even pkgname?
15 - properties are strings, stored in a string table
17 - on disk maps are binary files of (string table index, hash) pairs
19 - at run time, we mmap the map, and keep changes in memory in a splay
20 tree or similar. if searching the splay tree fails we punt to the
21 mmap. once the transaction is done, we merge the map and the splay
22 tree and write it back out.
24 - the on-disk string pool is sorted and we keep a list of indices into
25 the string pool in sorted order so we can bsearch the list with a
26 string to get its string pool index. maybe a hash table is better,
27 less I/O as we will expect to find the string within the block we
28 look up with the hash function.
30 - represent all files as a breadth first traversal of the tree of all
31 files. each entry has its name (string pool index), the number of
32 immediate children, total number of children, and owning package.
33 for files both these numbers are zero. a file is identified by its
34 index in this flattened tree.
36 to get the file name from an index, we search through the list. by
37 summing up the number of children, we know when to skip a directory
38 and when to descend into one. as we go we accumulate the path
41 hmm, dropping number of immediate children and using a sentinel drops
42 a word from every entry.
46 - gzip repository of look-aside pkg xml files somehow?
48 - transactions, proper recovery, make sure we don't poop our package
49 database (no more rm /var/lib/rpm/__cache*).
51 - diff from one package set to another answers: "what changed in
52 rawhide between since yesterday?"
54 - rewrite qsort and bsearch that doesn't require global context var
55 and can output a map describing the permutaion.
57 - use hash table for package and property lists so we only store
58 unique lists (like for string pool).
60 - use existing, running system as repo; eg
62 razor update razor://other-box.local evince
64 to pull eg the latest evince and dependencies from another box. We
65 should be able to regenerate a rzr pkg from the system so we can
66 reuse the signature from the originating repo.
68 - Ok, maybe the fastest package set merge method in the end is to use
69 the razor_importer, but use a hash table for the properties. This
70 way we can assign them unique IDs immediately (like tokenizing
73 - bash completion for 'razor install gtk2-<TAB>' og
74 'razor install /usr/bin/gtk-perf<TAB>'
76 - test suite should be easy, just keep .repo files around and test
77 different type of upgrades that way (obsoletes, conflicts, file
78 conflicts, file/dir problems etc). Or maybe just keep a simple file
79 format ad use a custom importer to create the .repo files.
81 - pipelined download and install; download is network bound, install
82 is disk bound. Start installing once we have self-contained set of
83 packages. Install in reverse topo-sort order. Interruptible
84 installation; stops at nearest checkpoint.