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
7 - gzip repository of look-aside pkg xml files somehow?
9 - transactions, proper recovery, make sure we don't poop our package
10 database (no more rm /var/lib/rpm/__cache*).
12 - diff from one package set to another answers: "what changed in
13 rawhide between since yesterday?"
15 - rewrite qsort and bsearch that doesn't require global context var
16 and can output a map describing the permutaion.
18 - use hash table for package and property lists so we only store
19 unique lists (like for string pool).
21 - use existing, running system as repo; eg
23 razor update razor://other-box.local evince
25 to pull eg the latest evince and dependencies from another box. We
26 should be able to regenerate a rzr pkg from the system so we can
27 reuse the signature from the originating repo.
29 - Ok, maybe the fastest package set merge method in the end is to use
30 the razor_importer, but use a hash table for the properties. This
31 way we can assign them unique IDs immediately (like tokenizing
34 - test suite should be easy, just keep .repo files around and test
35 different type of upgrades that way (obsoletes, conflicts, file
36 conflicts, file/dir problems etc). Or maybe just keep a simple file
37 format ad use a custom importer to create the .repo files.
39 - pipelined download and install; download is network bound, install
40 is disk bound. Start installing once we have self-contained set of
41 packages. Install in reverse topo-sort order. Interruptible
42 installation; stops at nearest checkpoint.
44 - make packages pointers be either an index into the package pool or a
45 direct link to a package when there is only one package. set a high
46 bit to indicate which it is. similar for properties.
48 - split out hash table code from importer, make the merger use just
53 do { ... } while (((e++)->name & RAZOR_ENTRY_LAST) == 0);
55 idiom for iteration of directories.
57 - version the sections in the file, put the element size in the header
58 so we can add stuff to elements in a backwards compatible way.
60 - overlay package sets? mount a read-only /usr over nfs or from the
61 virt-host and have a local package set overlaid over the read-only
62 one. shouldn't need new features in the core package set data
63 structure, but should be just conventions on top. we have the base
64 package set from the r/o system, the overlay set from the local
65 system and we can have an effective package set which is the merge
66 of everything from the overlay into the base set. the effective set
67 is easy to compute and we could do it on the fly or cache it. or
68 maybe the effective set is the on-disk representation and the
69 overlay can be computed when needed, we just keep a link back to the