1.1 --- a/.gitignore	Wed Oct 24 00:32:18 2007 -0400
     1.2 +++ b/.gitignore	Wed Oct 24 00:50:29 2007 -0400
     1.3 @@ -5,3 +5,4 @@
     1.4  razor
     1.5  pkgs
     1.6  set
     1.7 +primary.xml.gz

     2.1 --- /dev/null	Thu Jan 01 00:00:00 1970 +0000
     2.2 +++ b/README	Wed Oct 24 00:50:29 2007 -0400
     2.3 @@ -0,0 +1,55 @@
     2.4 +Just random notes at this point:
     2.5 +
     2.6 + - Razor is a package management system replacing rpm and yum.  Razor
     2.7 +   implements management of packages installed on the system,
     2.8 +   dependency solving, and upgrading in a small compact code base with
     2.9 +   minimal dependencies.
    2.10 +
    2.11 + - Key points: one file format for package sets, specified and
    2.12 +   implemented by razor; no point in splitting dep-solver and package
    2.13 +   manager, there is too much implementation overlap.  By hand coding
    2.14 +   the on-disk format we have a solid foundation on which to
    2.15 +   implementing fast dependency solving, error recovery etc.  No
    2.16 +   complex dependencies in package management stack.  In other words,
    2.17 +   package management is *simple*, no need to overdesign it.
    2.18 +
    2.19 + - Use one simple file format as the core of the system.  The razor
    2.20 +   package set data structure represents a set of packages and is used
    2.21 +   for the current installed set, the sets available from upstream
    2.22 +   sources, and the set currently being install during a transaction.
    2.23 +   Tiered systems such as rpm+yum, deb+apt etc end up duplicating and
    2.24 +   reimplementing common operations on packages.  Other systems
    2.25 +   typically pull in external database libraries to manage the package
    2.26 +   meta data and in some cases each layer in the stack uses a
    2.27 +   different database dependency to represent essentially the same
    2.28 +   data.
    2.29 +
    2.30 + - Using external database libraries may seem a good idea up front,
    2.31 +   but monotone vs git is a good example of how you need to control
    2.32 +   the data structure and the on-disk format to really get excellent
    2.33 +   performance.  The razor package set data structure is fairly
    2.34 +   simple; it's an read-only, mmap()'able on-disk data structure.  The
    2.35 +   package set has a sorted index of the packages in the set, a sorted
    2.36 +   index of all dependencies and a sorted, compact directory of all
    2.37 +   files in all the packages.  Operations such as merging package
    2.38 +   sets, satisfying requires from one set against another can all be
    2.39 +   implemented in linear time.  Razor implements the package set
    2.40 +   representation down to the bytes on the disk and can optimize the
    2.41 +   representation and access methods to make the necessary operations
    2.42 +   fast and reliable.
    2.43 +
    2.44 + - The set of installed packages on a system is represented by just
    2.45 +   one package set file.  As we install a set of new packages, we
    2.46 +   prepare the new package set a temporary file and once the install
    2.47 +   has succeeded, we copy the package set file to the real filename.
    2.48 +   If there is a system crash, razor will notice the temporary file on
    2.49 +   boot and resume the update.  
    2.50 +
    2.51 + - We want to keep the numer of dependencies down in a system critical
    2.52 +   component such as the package manager.  Between rpm and yum we're
    2.53 +   pulling in berkeley db, sqlite, expat, python.
    2.54 +
    2.55 + - During update of several packages rpm+yum leaves the system in an
    2.56 +   inconsistent state for long periods of time.  Power failure in this
    2.57 +   window causes critical system corruption.  We want to minimize the
    2.58 +   window.