krh@65: Towards replacing rpm + yum (0.1):
krh@65: 
krh@82: - installer part:
krh@65: 
krh@82:    - pre install check; check that dirs can be created (no files where
krh@82:      want to create dirs), move config files according to file
krh@82:      flags. (.rpmnew etc)
krh@65: 
krh@82:    - store rpm headers for installed packages.
krh@65: 
krh@189: - rpm seems to consider glibc > 2.6.90 to mean greater than
krh@189:   2.6.90-anything.  That is, a comparison that doesn't mention the
krh@189:   release field, shouldn't regard the release field of pkgs it
krh@189:   compares against.  glibc-common-2.6.90 has
krh@189: 
krh@189: 	conflicts: glibc < 2.6.90, glibc > 2.6.90
krh@189: 
krh@189:   since rpm doesn't let you do glibc != 2.6.90, and
krh@189: 
krh@189: 	requires: glibc = 2.6.90
krh@189: 
krh@189:   will always pull in glibc.  But even with a != relation, would
krh@189:   glibc-2.6.90-16 be equal to 2.6.90?  glibc 2.7.90-8 dropped it in
krh@189:   favor of requires = 2.7.90-8 (#225806).
krh@189: 
krh@65: - signed packages
krh@65: 
krh@65: - figure out how to canonically represent empty string... ~0?
krh@65: 
krh@70: - space calculation before transaction, but ideally, do a number of
krh@70:   smaller transactions.
krh@70: 
krh@70: - pre-link changing binaries and libs on disk screwing up checksum?
krh@70: 
danw@180: - nail down byte-order of repo file.
krh@74: 
krh@74: - version the sections in the file, put the element size in the header
krh@74:   so we can add stuff to elements in a backwards compatible way.
krh@82:   maybe not necessary, we can just add sections that augment the
krh@82:   sections we want to add to (similar to how rpm has add versioned
krh@82:   deps).
krh@82: 
krh@82: - pipelined download and install; topo-sort packages in update set,
krh@82:   pick one with all deps in the current set, add it to the current set
krh@82:   and satisfy deps against update set => result: minimal update
krh@82:   transaction.  Queue download and install/update transaction for the
krh@82:   packages in the minimal set, start over.  This also makes the
krh@82:   installation phase much more interruptible, basically just stop
krh@82:   after a sub-transaction finishes.  As we keep the update set around
krh@82:   as a target, we can restart if needed.  Probably don't need to, can
krh@82:   just do a new update.  During a sub-transaction we should keep the
krh@82:   target set (i.e. the current set to be) around as a lock file
krh@82:   (system.repo.lock or so, see git) so that razor updates are
krh@82:   prevented if the systems crashes during an update.
krh@74: 
krh@65: Misc ideas:
krh@65: 
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@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: - 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@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: - 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.
krh@71: 
krh@71: - incremental rawhide repo updates? instead of downloading 10MB zipped
krh@82:   repo every time, download a diff repo?  Should be pretty small,
krh@82:   especially if we don't have file checksums in metadata.  Filenames
krh@82:   and properties are for the most part already present, typically just
krh@82:   a version bump plus maybe tweaking a couple requires.  The upstream
krh@82:   repo can store multiple incremental updates in one big file and
krh@82:   provide an index file that maps updates for a given date (we should
krh@82:   use repo-file checksums though) to a range in the file: Download the
krh@82:   index file, search for a match for your latest rawhide.repo file,
krh@82:   download range of updates that brings it up to date.
krh@74: 
krh@74: - use hash tables for dirs when importing files to avoid qsorting all
krh@74:   files in rawhide.
krh@75: 
krh@82: Bugs:
krh@82: 
krh@82: - eliminate duplicate entries in package property lists.