krh@65: Towards replacing rpm + yum (0.1): krh@65: krh@65: - installer part krh@65: krh@65: - rpm file parser, create repo command krh@65: krh@65: - conflicts, obsoletes krh@65: krh@65: - versions in depsolving krh@65: krh@65: - signed packages krh@65: krh@65: - merge file lists when merging package sets krh@65: krh@65: - download (libcurl?) 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: krh@74: - nail down byte-order and word sizes 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@74: krh@65: Misc ideas: krh@65: krh@66: - eliminate duplicate entries in package property lists. krh@66: 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: - 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: - 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@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: - 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@71: repo every time, download a diff repo? krh@74: krh@74: - use hash tables for dirs when importing files to avoid qsorting all krh@74: files in rawhide.