|
krh@1
|
1 |
- pkg manifest is list of files
|
|
krh@1
|
2 |
|
|
krh@1
|
3 |
/usr/bin/bash 1321321372198798
|
|
krh@1
|
4 |
|
|
krh@1
|
5 |
plus provides, requires and version?
|
|
krh@1
|
6 |
|
|
krh@1
|
7 |
- keep history of installed packages/journal of package transaction,
|
|
krh@1
|
8 |
so we can roll back to yesterday, or see what got installed in the
|
|
krh@1
|
9 |
latest yum update.
|
|
krh@1
|
10 |
|
|
krh@1
|
11 |
- we build a cache of the currently installed set to service
|
|
krh@1
|
12 |
dependency inquiries fast:
|
|
krh@1
|
13 |
|
|
krh@1
|
14 |
map from property to pkg (as hash) providing it
|
|
krh@1
|
15 |
map from property to pkgs requiring it
|
|
krh@1
|
16 |
map from pkg name to manifest
|
|
krh@1
|
17 |
map from string to string pool index
|
|
krh@1
|
18 |
|
|
krh@1
|
19 |
no implicit provides? not even pkgname?
|
|
krh@1
|
20 |
|
|
krh@1
|
21 |
- properties are strings, stored in a string table
|
|
krh@1
|
22 |
|
|
krh@1
|
23 |
- on disk maps are binary files of (string table index, hash) pairs
|
|
krh@1
|
24 |
|
|
krh@1
|
25 |
- at run time, we mmap the map, and keep changes in memory in a splay
|
|
krh@1
|
26 |
tree or similar. if searching the splay tree fails we punt to the
|
|
krh@1
|
27 |
mmap. once the transaction is done, we merge the map and the splay
|
|
krh@1
|
28 |
tree and write it back out.
|
|
krh@1
|
29 |
|
|
krh@1
|
30 |
- the on-disk string pool is sorted and we keep a list of indices into
|
|
krh@1
|
31 |
the string pool in sorted order so we can bsearch the list with a
|
|
krh@1
|
32 |
string to get its string pool index. maybe a hash table is better,
|
|
krh@1
|
33 |
less I/O as we will expect to find the string within the block we
|
|
krh@1
|
34 |
look up with the hash function.
|
|
krh@1
|
35 |
|
|
krh@5
|
36 |
- represent all files as a breadth first traversal of the tree of all
|
|
krh@5
|
37 |
files. each entry has its name (string pool index), the number of
|
|
krh@5
|
38 |
immediate children, total number of children, and owning package.
|
|
krh@5
|
39 |
for files both these numbers are zero. a file is identified by its
|
|
krh@5
|
40 |
index in this flattened tree.
|
|
krh@5
|
41 |
|
|
krh@5
|
42 |
to get the file name from an index, we search through the list. by
|
|
krh@5
|
43 |
summing up the number of children, we know when to skip a directory
|
|
krh@5
|
44 |
and when to descend into one. as we go we accumulate the path
|
|
krh@5
|
45 |
elements.
|
|
krh@5
|
46 |
|
|
krh@5
|
47 |
hmm, dropping number of immediate children and using a sentinel drops
|
|
krh@5
|
48 |
a word from every entry.
|
|
krh@5
|
49 |
|
|
krh@1
|
50 |
- signed pkgs
|
|
krh@1
|
51 |
- gzip pkg xml files somehow?
|