ali@374: This is a fork of Kristian Høgsberg's razor. The bits live here:
ali@374: 
ali@374: 	http://project.juiblex.co.uk/git?p=razor.git;a=summary
ali@374: 
ali@374: Kristian's original README follows:
ali@374: 
ali@374: ----------------------------------------------------------------------
krh@58: Just random notes at this point:
krh@58: 
krh@58:  - Razor is a package management system replacing rpm and yum.  Razor
krh@58:    implements management of packages installed on the system,
krh@58:    dependency solving, and upgrading in a small compact code base with
krh@58:    minimal dependencies.
krh@58: 
krh@58:  - Key points: one file format for package sets, specified and
krh@58:    implemented by razor; no point in splitting dep-solver and package
krh@58:    manager, there is too much implementation overlap.  By hand coding
krh@58:    the on-disk format we have a solid foundation on which to
krh@58:    implementing fast dependency solving, error recovery etc.  No
krh@58:    complex dependencies in package management stack.  In other words,
krh@58:    package management is *simple*, no need to overdesign it.
krh@58: 
krh@58:  - Use one simple file format as the core of the system.  The razor
krh@58:    package set data structure represents a set of packages and is used
krh@58:    for the current installed set, the sets available from upstream
krh@58:    sources, and the set currently being install during a transaction.
krh@58:    Tiered systems such as rpm+yum, deb+apt etc end up duplicating and
krh@58:    reimplementing common operations on packages.  Other systems
krh@58:    typically pull in external database libraries to manage the package
krh@58:    meta data and in some cases each layer in the stack uses a
krh@58:    different database dependency to represent essentially the same
krh@58:    data.
krh@58: 
krh@58:  - Using external database libraries may seem a good idea up front,
krh@58:    but monotone vs git is a good example of how you need to control
krh@58:    the data structure and the on-disk format to really get excellent
krh@58:    performance.  The razor package set data structure is fairly
krh@58:    simple; it's an read-only, mmap()'able on-disk data structure.  The
krh@58:    package set has a sorted index of the packages in the set, a sorted
krh@58:    index of all dependencies and a sorted, compact directory of all
krh@58:    files in all the packages.  Operations such as merging package
krh@58:    sets, satisfying requires from one set against another can all be
krh@58:    implemented in linear time.  Razor implements the package set
krh@58:    representation down to the bytes on the disk and can optimize the
krh@58:    representation and access methods to make the necessary operations
krh@58:    fast and reliable.
krh@58: 
krh@58:  - The set of installed packages on a system is represented by just
krh@58:    one package set file.  As we install a set of new packages, we
krh@58:    prepare the new package set a temporary file and once the install
krh@58:    has succeeded, we copy the package set file to the real filename.
krh@58:    If there is a system crash, razor will notice the temporary file on
krh@58:    boot and resume the update.  
krh@58: 
krh@58:  - We want to keep the numer of dependencies down in a system critical
krh@58:    component such as the package manager.  Between rpm and yum we're
krh@58:    pulling in berkeley db, sqlite, expat, python.
krh@58: 
krh@58:  - During update of several packages rpm+yum leaves the system in an
krh@58:    inconsistent state for long periods of time.  Power failure in this
krh@58:    window causes critical system corruption.  We want to minimize the
krh@58:    window.