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