TODO
author Kristian H?gsberg <krh@redhat.com>
Sun Nov 04 01:11:53 2007 -0400 (2007-11-04)
changeset 70 e94d16f789e5
parent 66 bb4ca4a47f66
child 71 befb5208c022
permissions -rw-r--r--
Parse filelists.xml.gz too, so we import the yum files too.
     1 Towards replacing rpm + yum (0.1):
     2 
     3 - installer part
     4 
     5 - rpm file parser, create repo command
     6 
     7 - conflicts, obsoletes
     8 
     9 - versions in depsolving
    10 
    11 - signed packages
    12 
    13 - merge file lists when merging package sets
    14 
    15 - import filelist.xml.gz too in yum importer
    16 
    17 - download (libcurl?)
    18 
    19 - figure out how to canonically represent empty string... ~0?
    20 
    21 - space calculation before transaction, but ideally, do a number of
    22   smaller transactions.
    23 
    24 - pre-link changing binaries and libs on disk screwing up checksum?
    25 
    26 Misc ideas:
    27 
    28 - eliminate duplicate entries in package property lists.
    29 
    30 - keep history of installed packages/journal of package transaction,
    31   so we can roll back to yesterday, or see what got installed in the
    32   latest yum update.
    33 
    34 - gzip repository of look-aside pkg xml files somehow?
    35 
    36 - transactions, proper recovery, make sure we don't poop our package
    37   database (no more rm /var/lib/rpm/__cache*).
    38 
    39 - rewrite qsort and bsearch that doesn't require global context var
    40   and can output a map describing the permutaion.
    41 
    42 - use hash table for package and property lists so we only store
    43   unique lists (like for string pool).
    44 
    45 - use existing, running system as repo; eg
    46 
    47 	razor update razor://other-box.local evince
    48 
    49   to pull eg the latest evince and dependencies from another box.  We
    50   should be able to regenerate a rzr pkg from the system so we can
    51   reuse the signature from the originating repo.
    52 
    53 - Ok, maybe the fastest package set merge method in the end is to use
    54   the razor_importer, but use a hash table for the properties.  This
    55   way we can assign them unique IDs immediately (like tokenizing
    56   strings).
    57 
    58 - test suite should be easy, just keep .repo files around and test
    59   different type of upgrades that way (obsoletes, conflicts, file
    60   conflicts, file/dir problems etc).  Or maybe just keep a simple file
    61   format ad use a custom importer to create the .repo files.
    62 
    63 - pipelined download and install; download is network bound, install
    64   is disk bound.  Start installing once we have self-contained set of
    65   packages.  Install in reverse topo-sort order.  Interruptible
    66   installation; stops at nearest checkpoint.
    67 
    68 - split out hash table code from importer, make the merger use just
    69   the hash table.
    70 
    71 - try to clean up the
    72 
    73 	do { ... } while (((e++)->name & RAZOR_ENTRY_LAST) == 0);
    74 
    75   idiom for iteration of directories.
    76 
    77 - version the sections in the file, put the element size in the header
    78   so we can add stuff to elements in a backwards compatible way.
    79 
    80 - overlay package sets?  mount a read-only /usr over nfs or from the
    81   virt-host and have a local package set overlaid over the read-only
    82   one.  shouldn't need new features in the core package set data
    83   structure, but should be just conventions on top.  we have the base
    84   package set from the r/o system, the overlay set from the local
    85   system and we can have an effective package set which is the merge
    86   of everything from the overlay into the base set.  the effective set
    87   is easy to compute and we could do it on the fly or cache it.  or
    88   maybe the effective set is the on-disk representation and the
    89   overlay can be computed when needed, we just keep a link back to the
    90   base.