krh@1: - keep history of installed packages/journal of package transaction,
krh@1:   so we can roll back to yesterday, or see what got installed in the
krh@1:   latest yum update.
krh@1: 
krh@1: - signed pkgs
krh@8: 
krh@8: - gzip repository of look-aside pkg xml files somehow?
krh@8: 
krh@8: - transactions, proper recovery, make sure we don't poop our package
krh@8:   database (no more rm /var/lib/rpm/__cache*).
krh@8: 
krh@18: - diff from one package set to another answers: "what changed in
krh@18:   rawhide between since yesterday?"
krh@18: 
krh@18: - rewrite qsort and bsearch that doesn't require global context var
krh@18:   and can output a map describing the permutaion.
krh@18: 
krh@18: - use hash table for package and property lists so we only store
krh@18:   unique lists (like for string pool).
krh@40: 
krh@40: - use existing, running system as repo; eg
krh@40: 
krh@40: 	razor update razor://other-box.local evince
krh@40: 
krh@40:   to pull eg the latest evince and dependencies from another box.  We
krh@40:   should be able to regenerate a rzr pkg from the system so we can
krh@40:   reuse the signature from the originating repo.
krh@41: 
krh@41: - Ok, maybe the fastest package set merge method in the end is to use
krh@41:   the razor_importer, but use a hash table for the properties.  This
krh@41:   way we can assign them unique IDs immediately (like tokenizing
krh@41:   strings).
krh@47: 
krh@47: - test suite should be easy, just keep .repo files around and test
krh@47:   different type of upgrades that way (obsoletes, conflicts, file
krh@47:   conflicts, file/dir problems etc).  Or maybe just keep a simple file
krh@47:   format ad use a custom importer to create the .repo files.
krh@47: 
krh@51: - pipelined download and install; download is network bound, install
krh@51:   is disk bound.  Start installing once we have self-contained set of
krh@51:   packages.  Install in reverse topo-sort order.  Interruptible
krh@51:   installation; stops at nearest checkpoint.
krh@52: 
krh@52: - make packages pointers be either an index into the package pool or a
krh@52:   direct link to a package when there is only one package.  set a high
krh@52:   bit to indicate which it is.  similar for properties.
krh@55: 
krh@55: - split out hash table code from importer, make the merger use just
krh@55:   the hash table.
krh@56: 
krh@56: - try to clean up the
krh@56: 
krh@56: 	do { ... } while (((e++)->name & RAZOR_ENTRY_LAST) == 0);
krh@56: 
krh@56:   idiom for iteration of directories.
krh@63: 
krh@63: - version the sections in the file, put the element size in the header
krh@63:   so we can add stuff to elements in a backwards compatible way.
krh@63: 
krh@63: - overlay package sets?  mount a read-only /usr over nfs or from the
krh@63:   virt-host and have a local package set overlaid over the read-only
krh@63:   one.  shouldn't need new features in the core package set data
krh@63:   structure, but should be just conventions on top.  we have the base
krh@63:   package set from the r/o system, the overlay set from the local
krh@63:   system and we can have an effective package set which is the merge
krh@63:   of everything from the overlay into the base set.  the effective set
krh@63:   is easy to compute and we could do it on the fly or cache it.  or
krh@63:   maybe the effective set is the on-disk representation and the
krh@63:   overlay can be computed when needed, we just keep a link back to the
krh@63:   base.