1.1 --- /dev/null	Thu Jan 01 00:00:00 1970 +0000
     1.2 +++ b/README	Thu Jan 08 17:36:50 2009 +0000
     1.3 @@ -0,0 +1,55 @@
     1.4 +Just random notes at this point:
     1.5 +
     1.6 + - Razor is a package management system replacing rpm and yum.  Razor
     1.7 +   implements management of packages installed on the system,
     1.8 +   dependency solving, and upgrading in a small compact code base with
     1.9 +   minimal dependencies.
    1.10 +
    1.11 + - Key points: one file format for package sets, specified and
    1.12 +   implemented by razor; no point in splitting dep-solver and package
    1.13 +   manager, there is too much implementation overlap.  By hand coding
    1.14 +   the on-disk format we have a solid foundation on which to
    1.15 +   implementing fast dependency solving, error recovery etc.  No
    1.16 +   complex dependencies in package management stack.  In other words,
    1.17 +   package management is *simple*, no need to overdesign it.
    1.18 +
    1.19 + - Use one simple file format as the core of the system.  The razor
    1.20 +   package set data structure represents a set of packages and is used
    1.21 +   for the current installed set, the sets available from upstream
    1.22 +   sources, and the set currently being install during a transaction.
    1.23 +   Tiered systems such as rpm+yum, deb+apt etc end up duplicating and
    1.24 +   reimplementing common operations on packages.  Other systems
    1.25 +   typically pull in external database libraries to manage the package
    1.26 +   meta data and in some cases each layer in the stack uses a
    1.27 +   different database dependency to represent essentially the same
    1.28 +   data.
    1.29 +
    1.30 + - Using external database libraries may seem a good idea up front,
    1.31 +   but monotone vs git is a good example of how you need to control
    1.32 +   the data structure and the on-disk format to really get excellent
    1.33 +   performance.  The razor package set data structure is fairly
    1.34 +   simple; it's an read-only, mmap()'able on-disk data structure.  The
    1.35 +   package set has a sorted index of the packages in the set, a sorted
    1.36 +   index of all dependencies and a sorted, compact directory of all
    1.37 +   files in all the packages.  Operations such as merging package
    1.38 +   sets, satisfying requires from one set against another can all be
    1.39 +   implemented in linear time.  Razor implements the package set
    1.40 +   representation down to the bytes on the disk and can optimize the
    1.41 +   representation and access methods to make the necessary operations
    1.42 +   fast and reliable.
    1.43 +
    1.44 + - The set of installed packages on a system is represented by just
    1.45 +   one package set file.  As we install a set of new packages, we
    1.46 +   prepare the new package set a temporary file and once the install
    1.47 +   has succeeded, we copy the package set file to the real filename.
    1.48 +   If there is a system crash, razor will notice the temporary file on
    1.49 +   boot and resume the update.  
    1.50 +
    1.51 + - We want to keep the numer of dependencies down in a system critical
    1.52 +   component such as the package manager.  Between rpm and yum we're
    1.53 +   pulling in berkeley db, sqlite, expat, python.
    1.54 +
    1.55 + - During update of several packages rpm+yum leaves the system in an
    1.56 +   inconsistent state for long periods of time.  Power failure in this
    1.57 +   window causes critical system corruption.  We want to minimize the
    1.58 +   window.